Module relation_has_many_crud 

Test basic has_many associations without any preloading of associations during query time. All associations are accessed via queries on demand.

Modules

has_many_insert_on_update

Functions

assign_existing_user_to_todo

assign_todo_that_already_has_user_on_create

assign_todo_that_already_has_user_on_update

assign_todo_to_user_on_update_query

associate_new_user_with_todo_on_update_query_via_creation

associate_new_user_with_todo_on_update_via_creation

belongs_to_required

crud_user_todos

delete_when_belongs_to_optional

has_many_apply_combinations

Deterministic matrix over batch shapes. For each (existing, insert, remove) combination, build one stmt::apply([...]) carrying insert new children plus remove dissociations, then compare the resulting association set against a reference computed in memory. This covers larger batches and more combinations than the targeted tests above without the non-determinism (and sync/async friction) of a proptest runner.

has_many_apply_empty_is_noop

stmt::apply([]) on a has-many is a no-op: the surface API’s empty Apply loop adds no entry to the assignments map, so the relation field is treated as unchanged. Run alongside a separate scalar change because the engine verifier rejects updates with no assignments at all.

has_many_apply_insert_and_remove

stmt::apply([insert(..), remove(..)]) mixes Insert and Remove on a has-many in one update. Each entry dispatches as its own Mutation: the Insert associates the new child; the Remove dissociates the old one (and for a required FK, deletes it).

has_many_apply_insert_and_remove_nullable_fk

stmt::apply([insert(..), remove(..)]) on a has-many with a nullable foreign key. Unlike the required-FK case (which deletes the child), Remove here takes the disassociate-nullify branch: the old todo persists with its FK set to NULL.

has_many_apply_insert_remove_same_item

Inserting and removing the same existing record in one batch honors entry order. insert(&t) (associate an existing row) and remove(&t) (dissociate it) both lower to UPDATEs on the same row; the batch sequences its entries so the last-written op wins, instead of the two UPDATEs racing in the dependency graph.

has_many_apply_multiple_inserts

has_many_apply_multiple_removes

stmt::apply([remove(a), remove(b)]) — only disassociations, no Insert. flatten_relation_batch pushes no merged Insert, so both entries dispatch as standalone Disassociate mutations.

has_many_apply_nested

Nested stmt::apply([apply([..]), ..]). The surface API flattens nested applies into a single flat Batch (the engine never sees nesting), so this must behave identically to the equivalent flat batch. Guards the flattening contract — if nesting ever stopped flattening, the engine’s flatten_relation_batch dispatch would hit its unreachable! arm.

has_many_apply_remove_then_insert

stmt::apply([remove(..), insert(..)]) — the reverse of has_many_apply_insert_and_remove. flatten_relation_batch always emits the merged Insert first, so the final state is order-independent: the new child is associated and the old one is removed.

has_many_apply_swap_unique_required_fk

Order-sensitive swap: the child has a #[unique] title and we replace the “X” todo by removing the old one and inserting a fresh “X”. With a required FK, remove deletes the old row (freeing the unique title), so the insert can reuse it — but only if the delete runs first.

has_many_apply_swap_unique_with_extra_insert

Same unique-title swap, but with an unrelated insert at the front of the batch. flatten_relation_batch merges all inserts into one multi-row INSERT, so the unrelated “Y” insert and the swap’s new “X” insert become a single statement. That merged INSERT must still be dispatched after the remove, or the new “X” collides with the old one on the unique constraint — i.e. coalescing inserts must not pull them ahead of removes.

has_many_apply_two_inserts_and_remove

stmt::apply([insert(a), insert(b), remove(c)]) — multiple inserts merge into one multi-row INSERT, dispatched alongside a separate Remove. Exercises the Insert-merge path plus a sibling disassociate.

has_many_update_remove

Sanity check for plain update().todos(stmt::remove(..)) — no apply involved. With a required FK, Remove deletes the child row.

has_many_when_fk_is_composite

has_many_when_fk_is_composite_with_snippets

scoped_find_by_id

update_user_with_null_todo_is_err