#[belongs_to] inside an embedded struct: same storage rule — the key
field owns the column, the relation maps to nothing — through the full
CRUD cycle.
The polymorphic-owner shape: #[belongs_to] fields inside embedded enum
variants, exercised through the full CRUD cycle. The relation fields map
to no columns — the discriminant and the key fields own the storage.
Creating supplies the variant value with explicit keys, match reads the
stored keys back, the owner loads with an ordinary get_by_*, and
changing the owner — including its kind — is a whole-value replacement of
the embed.
Comparing one embedded relation to another substitutes the key on both
sides of the comparison. Rewriting only one side would leave the other
as the relation’s storage-less record slot, which lowers to Null and
matches nothing.
Comparing two relations that live in enum variants requires both
variants. Every variant here stores its key in the same shared column,
so without both checks a row holding Other on either side would match
on key equality alone. ne keeps both checks as well, and negating an
equality negates the guarded comparison as a whole.
Key fields of relation-carrying variants stay queryable through the
existing variant filter paths — the variant closure gates on the
discriminant and compares the shared key column — and stay consistent
as rows are re-pointed and deleted.
Filtering an embedded relation by model value. The comparison gates on
the variant’s discriminant and compares the key column — a row of another
variant holding the same key in the shared column never matches — and
traversal into the target model lifts to a subquery behind the same gate.
List membership on a relation inside an embedded enum variant: the
relation resolves to its variant-scoped key column, so an Animal row
holding one of the listed humans’ ids in the shared key column does not
match.
Filtering a relation inside an embedded struct by model value: no
discriminant exists, the comparison resolves to the key column through
the embed path, and traversal lifts to a subquery.
Every predicate through the nested path requires both variants, whether
the comparison is at the relation, a path converted through IntoExpr,
or a check of the inner variant.
Traversal into the target of the nested composite-key relation. A filter
through a composite foreign key lifts to a tuple IN subquery, which
only the SQL backends evaluate.
An Option<Owner> field: an ownerless row stores NULL in the discriminant
column, per existing optional-embed support, and updates move rows in and
out of ownership.
A predicate assembled from the statement AST, rather than through the
typed constructors, requires the variant it selects all the same: the
engine attaches the check when it normalizes the statement.
A variant literal inside an embedded partial patch replaces the nested
enum field as a whole while the patch leaves the sibling field alone,
for both instance and query targets.
The values written in a variant literal are evaluated before the update
target is borrowed, as a match scrutinee: a reference to a temporary
stays valid for the chain, and an inference-dependent value takes its
type from the monomorphic builder setter.
A variant literal written into an Option<Enum> field: the builder
converts to the optional expression, so no Some(..) wrapper is needed
in create! or update!.
Setting an embedded relation from a parent model value. In create! and
update!, a variant literal passes the parent by reference and the key
field fills from the parent’s referenced field — including a non-primary
references = serial key. In a plain (complete) literal, a loaded
relation value fills the key the same way, winning over the explicitly
written key.