Module embed_enum_shared_column 

Functions

raw_shared_identifier_uses_bare_name

shared_column_cross_variant_or

OR-ing the two variant-gated predicates on the shared creature_name column is the natural way to query a single shared column across variants: “any creature named Bob, regardless of variant”. This used to panic in the SQL serializer (issue #1061) because factoring lifted the shared predicate out from under its variant gates, exposing the decode’s unreachable Error else branch.

shared_column_db_schema

A field declared #[shared(name)] in two variants coalesces into a single shared, nullable column rather than producing one column per variant. The table therefore has exactly one creature_name column alongside each variant’s own distinct column.

shared_column_roundtrip

Both variants write and read the shared column, while their variant-specific columns round-trip independently.

shared_column_schema_fields

The #[shared(name)] declaration surfaces in the app schema as the field’s shared identifier; both variants’ name fields carry the same identifier, which is what drives the column coalescing.

shared_column_update

Updating the whole enum field — including switching variants — re-encodes the shared column correctly. The merged per-variant encode must select the arm matching the new discriminant, so the shared column follows the value into its new variant while the old variant’s column is cleared to NULL.

shared_column_variant_gated_filter

Both variants store their name in the same physical creature_name column. A variant-rooted filter on that column keeps its implicit variant gate, so human().name().eq("Bob") matches only Human rows even though an Animal stores the same value in the same column — the discriminant disambiguates the shared column per variant.