How does a version value survive the round trip when a record is read, edited in a client, and posted back?

## The window this is really about A guard that compares versions inside a single short transaction rarely fires - the read and the write are milliseconds apart. The window that matters is the **detached** one: a record is read, rendered for a person, edited while they think, and posted back minutes later. Two people can easily open the same record in that time. If the version does not survive the trip out and back, the guard is decorative. ## What the transfer model must carry A transfer model is the flat shape the boundary hands to the client, not the tracked object itself. To keep the guard alive it needs one extra field: - **Outbound**, the version the record had when it was read, alongside the editable fields. - **Inbound**, the same value, returned unchanged with the submitted edit. - **Opaque to the client.** The client is a courier, not an author: it must never compute, increment or invent the value, only echo it. - **Mandatory on write.** A submission without a version cannot be checked, so the boundary should reject it rather than write blind. ## The mistake that silently disables the guard The write path most people reach for first is: 1. Load the row by identifier, in a fresh unit of work. 2. Copy the submitted fields onto the loaded object. 3. Let the unit commit. Every step looks reasonable, and the guarded update is genuinely emitted - with the version that was loaded **one millisecond ago**, which of course still matches. The check passes unconditionally. The edit that another user committed during the person's thinking time is overwritten with fields calculated from stale values, and nothing anywhere reports a problem. This is the single most common way an application ships version columns and lost updates at the same time. ## Two ways to make the submitted version the one that counts | Approach | How it works | Notes | |---|---|---| | Compare before writing | Load the row, compare its current version with the submitted one, and refuse if they differ | Simple and explicit; the tiny gap to the write is still covered by the guarded statement | | Write with the submitted version | Put the client's version onto the object so the guard compares it | Fewest moving parts, but only some layers let the field be set that way | Both end with the same property: a submission based on a stale view cannot be written. The explicit comparison also gives a natural place to build the message the user will see. ## What the user gets back A rejection is a product decision, not just an error code. The useful responses are: - **Show what changed.** Return the current values so the person can see who moved what, and re-submit against the new version. - **Re-apply the intent.** Where the edit is expressible as a delta rather than an absolute value - add a note, increment a count - the server can redo it against the current row instead of bouncing it back. - **Never silently accept.** Discarding the version and writing anyway is the behaviour the whole mechanism exists to prevent. ## Partial submissions and multi-step forms Two details bite in practice. First, if the client posts only the fields it changed, the version still has to come with them; a partial submission is not an excuse to skip the check. Second, a wizard that reads a record on step one and writes on step four should carry the version from step one, not re-read it at step three - otherwise the check only covers the last few seconds of a long interaction. ## Serialisation is part of the contract The value has to survive the encoding both ways. A counter passed through a format that treats large numbers loosely, or a timestamp truncated to a coarser precision when it is formatted, comes back as something that no longer equals what is stored - which turns into either a permanent false conflict or, worse, a comparison that matches when it should not. Keep the value in a form the wire format represents exactly, and treat it as a string token at the boundary if there is any doubt. ## The rule to remember The guard compares the state of the row against the state **the editor saw**. Every design decision above is in service of that single sentence: whatever is compared in the `WHERE` clause must trace back to the moment the human looked at the screen, not to the moment the server started handling the submission.