As a developer I want to add optimistic versioning to TaskBody so that two concurrent updates to the same task can't silently overwrite each other.
Assumptions & Constraints
- Uses the standard JPA
version field, a long column that increments on every update.
- This is purely a concurrency safeguard, it doesn't change any business rule or existing field.
- A concurrent update conflict should surface as a clear error to the caller.
Preconditions
TaskBody entity and its migration already exist.
Business rules
- Every update to a
TaskBody row increments its version.
- An update based on a stale version is rejected, not silently applied.
- Creating a new
TaskBody starts at the initial version, no special handling needed there.
Acceptance Criteria
task_bodies has a version column, not null, defaulting to 0.
- The entity has a
version field mapped to that column.
- Updating a
TaskBody with a stale version results in a clear, mapped error response.
- A normal, non concurrent update still works exactly as before.
Out of scope
- Any UI handling for a version conflict, that's a separate concern once this exists.
- Adding versioning to any entity other than
TaskBody.
Epic link
Epic #6 - EPIC: Tasks
Tasks
As a developer I want to add optimistic versioning to
TaskBodyso that two concurrent updates to the same task can't silently overwrite each other.Assumptions & Constraints
versionfield, a long column that increments on every update.Preconditions
TaskBodyentity and its migration already exist.Business rules
TaskBodyrow increments its version.TaskBodystarts at the initial version, no special handling needed there.Acceptance Criteria
task_bodieshas aversioncolumn, not null, defaulting to 0.versionfield mapped to that column.TaskBodywith a stale version results in a clear, mapped error response.Out of scope
TaskBody.Epic link
Epic #6 - EPIC: Tasks
Tasks
versioncolumn migration fortask_bodies.versionfield toTaskBody.