26 lines
1.4 KiB
Markdown
26 lines
1.4 KiB
Markdown
# ADR-0002: Use float sort_order for drag-and-drop ordering
|
||
|
||
## Status
|
||
|
||
accepted
|
||
|
||
## Context
|
||
|
||
The planning screens (PBI list, Story list, Task list, Solo board) all support drag-and-drop reordering. With integer positions, inserting an item between positions 3 and 4 requires renumbering every subsequent row — an O(N) write for every drag operation. At the scale of a sprint board this is tolerable, but it causes unnecessary lock contention and makes optimistic UI rollback harder. See `docs/patterns/sort-order.md` for the full implementation pattern.
|
||
|
||
## Decision
|
||
|
||
Every ordered collection uses a `Float` column named `sort_order`. Inserting between two items sets `sort_order = (prev + next) / 2`. New items appended to the end get `last + 1.0`.
|
||
|
||
## Consequences
|
||
|
||
### Positive
|
||
|
||
- Reorder writes are O(1) — only the moved item's row is updated.
|
||
- Optimistic UI updates map directly to the same midpoint calculation.
|
||
- No lock contention on adjacent rows during concurrent drags.
|
||
|
||
### Negative
|
||
|
||
- Repeated insertions between the same two items cause float precision drift. Mitigation: a periodic compaction job normalizes `sort_order` values to integers × 1000 when the gap drops below `0.001`. This is a known trade-off; compaction has not been needed in practice yet.
|
||
- Queries that return items in `sort_order` order must always include `ORDER BY sort_order` — there is no implicit ordering.
|