ddl2cpp emits PrimaryKey::AutoAssign on every member of a composite key, which GenerateAutoAssignPrimaryKey now rejects

[christianparpart]

Problem

With PrimaryKeyAssignment: ClientSide, CxxModelPrinter appends , Light::PrimaryKey::AutoAssign to every primary-key column (src/Lightweight/Tools/CxxModelPrinter.cpp:952-959, applied at :1083). For a table with a composite primary key — a junction table, typically — that emits several auto-assigned key members:

struct RlMxnFormelliste final
{
    static constexpr std::string_view TableName = "RL_MXN_FORMELLISTE";
    Light::Field<int32_t, Light::PrimaryKey::AutoAssign, Light::SqlRealName { "FORMEL_NR" }> formelNr;
    Light::Field<int32_t, Light::PrimaryKey::AutoAssign, Light::SqlRealName { "LISTE_NR" }> listeNr;
    Light::Field<std::optional<int32_t>, Light::SqlRealName { "LFD_NR" }> lfdNr;
};

DataMapper::Create() on such a record is now a hard compile error, from the static_assert added in GenerateAutoAssignPrimaryKey (DataMapper.hpp:1878). So ddl2cpp generates code that the DataMapper rejects.

The assert is right — docs/composite-keys-design.md states the rule, and SetId() does write the single generated value into every IsPrimaryKey member. The generator simply has not caught up; composite-keys-design.md lists ddl2cpp generation under "Deferred".

Impact

A downstream model of 688 generated entities has 165 with more than one AutoAssign key member. Only those actually passed to Create<>() instantiate the assert, so this surfaces as a scattered, hard-to-attribute build break on upgrade rather than all at once.

Before the assert existed this was silently dangerous rather than harmless: GenerateAutoAssignPrimaryKey only generates when a key field still holds its default, so a caller supplying both parts is fine — but a caller leaving either at 0 gets SELECT MAX(thatColumn)+1 written into every key member, overwriting the part it did supply.

What the fix needs to decide

Suppressing AutoAssign for composite keys is the easy half. The harder half is what to emit instead, because none of the three enumerators expresses "composite key, values supplied by the caller":

• PrimaryKey::No — loses key-ness; QuerySingle, Update and Delete by key stop working.
• PrimaryKey::AutoAssign — rejected by the new assert.
• PrimaryKey::ServerSideAutoIncrement — what composite-keys-design.md shows for CkParent, but Create() then runs if constexpr (HasAutoIncrementPrimaryKey<Record>) SetId(record, pk);, and SetId writes into every key member. That reintroduces the same clobbering after the insert rather than before it.

So this may need a fourth enumerator (a plain "part of the key, never generated") before ddl2cpp has something correct to emit. Happy to take that on if the shape is agreed.

Reproducing

Any table with a composite primary key, generated with PrimaryKeyAssignment: ClientSide, then passed to DataMapper::Create().

[Yaraslaut]

Confirmed against v0.20260921.0 while upgrading a downstream pin. Two findings that change the picture here.

PrimaryKey::No is not just lossy — it does not compile

The issue lists PrimaryKey::No as the option that "loses key-ness". It is worse than that: a record with no primary key member cannot go through Create() at all.

Create() ends with a bare if constexpr and no else (DataMapper.hpp:2131-2133):

if constexpr (HasPrimaryKey<Record>)
    return GetPrimaryKeyField(record);
}

For a keyless record RecordPrimaryKeyType resolves to std::monostate, not void — so this is a non-void function falling off the end, not a benign empty return. MSVC rejects it with C4716: must return a value, which is an error under /WX; on a compiler that only warns it is UB if reached.

So the "just drop the annotation" workaround the static_assert message itself recommends ("declare the key members without PrimaryKey::AutoAssign") does not actually work through Create(). Worth fixing independently of the generator question, since the assert's advice currently points at a broken path.

CreateExplicit() is a working escape hatch today

CreateExplicit() delegates straight to CreateInternal<PrimaryKeySource::Record> and touches neither GenerateAutoAssignPrimaryKey() nor the SetId() write-back. So for the caller-supplied composite-key case it already does the right thing: binds the values as given, generates nothing, clobbers nothing.

That gives an unblock for this case without waiting on the enumerator decision — drop the key annotation on the generated members and insert via CreateExplicit(). It costs key-ness (no QuerySingle/Update/Delete by key), which is acceptable for an insert-only junction table but not a general answer.

On the fourth enumerator

The analysis above still holds, and the two points reinforce it: there is currently no spelling for "part of the key, never generated". Both existing key enumerators pick a generation strategy, and the only annotation that avoids generation (No) drops out of the key set entirely — and lands on the Create() gap above.

If a fourth enumerator lands, the Create() no-key path is worth closing in the same pass, so the assert's suggested workaround stops being a dead end.

Happy to send a PR for the Create() return-path fix on its own if that is useful ahead of the generator work.