Module field_version 

Functions

batch_insert_checks_version

Batch-creating multiple versioned items should initialize all versions to 1, and a duplicate within the batch should fail.

create_initializes_version

A newly created record starts with version == 1.

delete_checks_version

Deleting a record checks the version — a fresh handle succeeds.

duplicate_create_fails

Creating the same primary key twice should fail. On DynamoDB the insert carries an attribute_not_exists condition on the version column; on SQL backends the primary-key constraint rejects the duplicate.

query_relative_update_increments_value_and_version

The query-based counterpart to relative_update_increments_value_and_version: a relative assignment (value += 1) on a versioned model through a query-rooted update.

query_update_increments_version

A query-based update increments the version, just like an instance update. This is the single-key path (filter by primary key).

query_update_invalidates_stale_instance

A query-based update bumps the version, so a concurrent instance update from a snapshot taken before the query update fails its OCC check rather than silently clobbering the query update’s write.

query_update_multi_key_works

Query-based update on a versioned model matching multiple rows. On DynamoDB this exercises update_by_key path 2 (no unique index, N keys via transact_write_items); on SQL backends it is a single multi-row UPDATE.

query_update_unique_index_increments_version

Query-based update through the unique-index path (path 3) increments the version. The version is a non-unique column, so it rides along in the main update expression alongside the unique-index surgery.

relative_update_after_delete_fails

The read-back variant of update_after_delete_fails: a relative update (increment) carries a RETURNING, so the conditional write goes through the row-returning path. With the row deleted there is nothing to return — the update fails rather than reloading the instance from a phantom row.

relative_update_increments_value_and_version

A relative update (increment) on a versioned model. The post-increment value can’t be computed client-side, so the driver returns it; the client-side #[version] bump rides along as a constant in the same returning projection. The two must not collide: the engine asks the driver for exactly the relative column, so the version value never lands in the returned row and shifts value out of its slot.

stale_delete_fails

Deleting from a stale snapshot (wrong version) should fail.

stale_update_fails

Two updates from the same stale snapshot — the second should fail with a condition-check error because the DB version has already moved to 2.

unique_index_stale_update_fails

Stale update on a model with a unique index: the second update from a stale snapshot should fail.

unique_index_update_increments_version

Updating a record through the unique-index path (path 3) increments the version when the unique column changes.

update_after_delete_fails

An instance update whose row has been deleted fails instead of silently succeeding. SQL backends raise record_not_found.

update_increments_version

Updating a record increments the version.

update_with_float_field_works

A conditional write binding a value whose database type cannot be inferred from the value alone (f64). Exercises bind-param type refinement through both SQL conditional-write plans (regression: the PostgreSQL CTE plan left f64 assignment params untyped and panicked).