Skip to content

Read schema 4 of the corpus - #32

Merged
tamnd merged 1 commit into
mainfrom
corpus-schema-4
Aug 21, 2026
Merged

Read schema 4 of the corpus#32
tamnd merged 1 commit into
mainfrom
corpus-schema-4

Conversation

@tamnd

@tamnd tamnd commented Aug 21, 2026

Copy link
Copy Markdown
Owner

The corpus moved to schema 4 in the engine and this client was two schemas behind it. The pin moves to 6ee7d80 and the reader learns everything the last two schemas added, which is three things arriving together because they arrive in the same files.

Connections. A case may name the connection it runs on, and a setup statement may name its own, so that a case about a transaction can say what the other connection sees. A named connection is made the first time a case names one, by duplicating the connection the case opened with, because the two then share the write side and that is what a pool hands out. Opening the path twice would be two databases that happen to be the same file, which is a different question and not the one a case about a transaction asks.

Graph values. A node is its table and the row it is, an edge is its table and the two rows it runs between, and a path is a sequence that alternates the two and holds an odd number of them. The engine's edge carries the position it holds among the edges out of its source, which the loader chose and no case writes down, so a value is normalised into the corpus's own shape before it is compared rather than compared against a number nobody picked.

The export. A case may say what the result gives through Arrow, field by field and into the nested types, or say that Arrow refuses it. That is read off the C Data Interface with ctypes rather than through pyarrow, for two reasons. pyarrow is not installed to run the corpus, so a check that needed it would be a check that quietly does not run. And the C runner reads the interface directly too, so the two runners are looking at the same bytes and reporting them in the same words, which is the whole reason a case writes a format string down. A refusal reaches this client as a TypeError for a column Arrow has no type for and a ValueError for one that will not fit, and both are caught around the call that raises them and nowhere wider, so a TypeError out of the ctypes reader is still a bug rather than a refusal.

Every refusal wording in the reader was checked against crates/zu-corpus/src rather than guessed at, and four of them differed from what I first wrote. The reader was right and the tests were wrong.

The corpus run is a session fixture now. Every case gets a database of its own and there are over a thousand, so two tests each running the whole corpus into a tmp_path was four gigabytes a run and three pytest generations of it, which filled a disk here. One run, under a directory that goes when the run does.

1268 cases, 1262 passed, 0 failed, 6 unsupported. All six are a time written to the nanosecond, which is a digit finer than a Python datetime holds, and each one says which value and why. 785 tests pass, ruff is clean.

The corpus moved to schema 4 in the engine and this client was two
schemas behind it, so the pin bump brings 1268 cases across a reader
that knew about none of what the last two added. Three things arrive
together because they arrive in the same files.

Connections. A case may name the connection it runs on, and a setup
statement may name its own, so that a case about a transaction can say
what the other connection sees. A named connection is made the first
time a case names one, by duplicating the connection the case opened
with, because the two then share the write side and that is what a pool
hands out. Opening the path twice would be two databases that happen to
be the same file, which is a different question and not the one a case
about a transaction asks.

Graph values. A node is its table and the row it is, an edge is its
table and the two rows it runs between, and a path is a sequence that
alternates the two and holds an odd number of them. The engine's edge
carries the position it holds among the edges out of its source, which
the loader chose and no case writes down, so a value is normalised into
the corpus's own shape before it is compared rather than compared
against a number nobody picked.

The export. A case may say what the result gives through Arrow, field
by field and into the nested types, or say that Arrow refuses it. That
is read off the C Data Interface with ctypes rather than through
pyarrow, for two reasons. pyarrow is not installed to run the corpus, so
a check that needed it would be a check that quietly does not run. And
the C runner reads the interface directly too, so the two runners are
looking at the same bytes and reporting them in the same words, which is
the whole reason a case writes a format string down.

The corpus run is a session fixture now. Every case gets a database of
its own and there are over a thousand, so two tests reading one report
were four gigabytes and three pytest generations of it, which filled a
disk. One run, in a directory that goes when the run does.

1268 cases, 1262 passed, 0 failed, 6 unsupported. All six are a time
written to the nanosecond, which is a digit finer than a Python
datetime holds, and each one says so.
@tamnd
tamnd merged commit 3b14b8e into main Aug 21, 2026
31 of 35 checks passed
@tamnd
tamnd deleted the corpus-schema-4 branch August 21, 2026 08:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant