Repository navigation
refactor(ledger): one layout table on every store, and content read in either byte shape - #291
Merged
rami-hatoum merged 2 commits intoOct 23, 2026
Conversation
…ery store The layout number was kept two ways, in PRAGMA user_version on SQLite and in the table ledger_layout on PostgreSQL: one fact, two code paths and two sets of words. A pragma is also a property of a file, not of a schema, so a store that is not a file has none. Both stores now keep it in ledger_layout, through the path PostgreSQL took: requireTheLayoutKept lists the tables of the schema, reads the row of ledger_layout when it is among them, and writes the table and its row into a database that holds none. All a store says for itself is where its tables are listed, sqlite_master or pg_tables in current_schema(). The behaviour suite's layout part proves the same refusals in the same words on both stores. On SQLite the step runs in a transaction of its own, which dumbo begins IMMEDIATE: of 20 pairs of pools that took it on one new file at once, one failed with "table ledger_layout already exists" statement by statement, and none in the transaction. The key of the one row is NOT NULL, since SQLite 3.53.4 let a second row in under a null key. The table is new on SQLite, so the layout is 2 and the pinned catalog holds it. A SQLite database made before is refused as one that holds tables but no layout number. The server's tests make a ledger of another version with aSQLiteFileInLayout of @on.auto/ledger/testing, which writes the layout as the ledger does. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ArrayBuffer The bytes of a chunk were decoded as a Uint8Array alone, where a SQL driver may answer an ArrayBuffer, which the standard byte APIs take as the same bytes. The read of a chunk now takes either and hands on a Uint8Array view of its bytes, through viewOf, so the shape a driver chooses is not the ledger's concern. sqlite3 6.0.1 and pg 8.23.1 both answer a Node Buffer, a Uint8Array, as a probe read; a test without a database reads a content back from each shape. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
rami-hatoum
deleted the
refactor/the-ledger-keeps-its-layout-number-in-a-table-on-every-store
branch
October 23, 2026 07:05
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
Two small debts of the ledger, each on its own terms.
The layout number is kept one way. It lived in
PRAGMA user_versionon SQLite and in the tableledger_layouton PostgreSQL: one fact, two code paths, two sets of words. A pragma is also a property of a file, not of a schema. Both stores now keep it inledger_layoutthrough the path PostgreSQL took, and all a store says for itself is where its tables are listed. On SQLite the step runs in one transaction, since the table takes two statements where the pragma took one, and the row's key isNOT NULL. The table is new on SQLite, so the layout is 2; a SQLite database made before is refused as one that holds tables but no layout number, and a local ledger made before this change is deleted, as any layout change asks. The server's tests make a ledger of another version through a new helper of the ledger's testing entry.A content read takes bytes in either shape. A chunk was decoded as a
Uint8Arrayalone, where a SQL driver may answer anArrayBuffer, which the standard byte APIs take as the same bytes. The read takes either and hands on aUint8Arrayview, so the shape a driver chooses is not the ledger's concern.Tests
ArrayBuffercase failed before.pnpm checkpasses on each commit, with the PostgreSQL suite running.