dolthub / dolthub/doltlite

rowid-keyed tables unsupported: rows are keyed by primary key, not rowid

Open
#1,840 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
268
Forks
18
Avg merge
2h 27m
Merged PRs (30d)
447

Description

DoltLite keys user-table rows in its prolly tree by the user's primary key
columns rather than by SQLite's auto-allocated rowid (since #358). Rowid is
allocation-order dependent and therefore history dependent, which is a hard
incompatibility with the Dolt model: two branches that independently insert
identical rows have to produce identical row identities, and a
content-addressed tree cannot do that if the key is "whichever integer this
connection handed out first".

Consequences, all of which inherited SQLite testfixture suites exercise:

- a table without an explicit INTEGER PRIMARY KEY is auto-converted to
WITHOUT ROWID, so `rowid` is not an addressable column — `WHERE rowid = N`
and `ORDER BY rowid` error with "no such column: rowid"
- an unordered `SELECT` returns user-PK order where stock SQLite returns
rowid (insertion) order
- `PRAGMA table_info` reports non-PK columns differently for auto-converted
WITHOUT ROWID tables
- AUTOINCREMENT and `sqlite_sequence` behavior tied to rowid allocation
- foreign key `SET NULL` / `SET DEFAULT` whose triggering DELETE addresses
parent rows by rowid

This is the single largest rationale in
`test/known_testfixture_divergences.txt` — its header block has documented it
at length, but with no issue to point at, so per-suite rows in
`test/known_testfixture_exception_inventory.txt` had nowhere to attribute it.
This issue is that anchor.

Not expected to be fixed; rowid-keyed storage is incompatible with the
version-control model rather than merely unimplemented.

### Attribution status

Attributed so far are the suites whose own recorded reason names rowid
explicitly (25 divergence suites plus `btreefault`, `incrblob`, `walbig`).
That is a floor, not the true count: most rowid-driven suites rely on the
header block instead of repeating the reason inline. Widening the attribution
is a triage pass over the remaining `intentional` rows and should not be
guessed at in bulk.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the rowid rationale in test/known_testfixture_divergences.txt and the intentional rows in test/known_testfixture_exception_inventory.txt. Review remaining entries for suites whose divergence is caused by rowid behavior, then attribute only supported cases in the inventory and preserve the header explanation; done means the issue is the anchor without speculative bulk attribution.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, sqlite
Domain
databases, documentation, testing
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
63/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.