RowVersioning OptimisticConcurrency

Row-level data versioning (a version/updated_at column used for optimistic locking) — distinct from MigrationTransfer/SchemaVersioning, which is about schema/DDL history, not row data.

Why we need this / what value this brings

Without it, two concurrent updates to the same row can silently overwrite each other with no error (the lost update problem) — the second write just wins, unnoticed.

When to use this

Any row that can be updated concurrently by more than one process/user and where losing an update silently would be a real problem (booking status, payment state).

How to use or implement this

Add a version or updated_at column, and make updates conditional on it matching the value that was read — reject (and let the caller retry) if it's changed since.

Research questions

• Does the booking table have any version column protecting against two concurrent updates silently overwriting each other (lost update problem)?

---

Empty folder — drop notes, links, and findings here as you research.