An enum-level attribute may reference a variant field that owns its column
via a variant::field path; combined with a shared field it produces a
composite index. Composite unique indices are SQL-only (DynamoDB does not
support them; see index_composite).
Two variant fields resolving to the same column name without a common
#[shared] identifier are a duplicate column, not an implicit merge. The
macro cannot catch this case (for embedded fields #[column] is a
flattening prefix, not a single column), so the schema builder rejects it.
Embedded-struct variant fields sharing a #[column("...")]prefix are
not a collision: the string prefixes each flattened leaf, so differently
shaped embeds produce disjoint columns.
Columns created while mapping a nested enum stay in the outer enum’s
namespace: a later variant field of the outer enum whose flattened name
collides with one of the nested enum’s columns is a duplicate, not a
silent second column.
Same collision as above, opposite order: the plain variant field comes
first and the nested enum second, so the nested enum’s variant fields must
be checked against column names the outer enum already created.
A #[column("...")] override on a shared group renames the shared column;
the shared identifier keeps naming the field in #[unique(...)], and the
index lands on the renamed column. The override needs declaring on only one
member of the group.
Uniqueness on a shared column is cross-variant: a Human and an Animal
with the same name conflict, matching the shared column’s un-gated query
semantics. Distinct names on either variant are accepted.