Skip to content

v0.10.0

@opticsWolf opticsWolf tagged this 08 Aug 07:40
A disarm switch nobody was watching, and a complexity claim that was wrong for
four releases.

No schema rung: v10, same as 0.9.0, so a 0.9.0 database opens with no migration
-- unless it carries a committed `macrame_archive_session` table, which
`Database::open` now refuses with `ArchiveSessionLeaked` (D-135). While that
table exists the delete guards on concepts, links and transaction_log all
evaluate false and concept inserts write no log row: Doctrine IV and Doctrine V
suspended, silently. No archive can strand it -- both paths create and drop it
inside one transaction -- so its presence means something wrote outside the
actor. The new variant is the API break that makes this 0.10.0 and not 0.9.1;
DbError is not #[non_exhaustive]. Python gains ArchiveSessionLeakedError.

The single-assertion budget was never O(out-degree). The caveat has been false
since 0.5.6, when idx_lc_open_interval shipped, and survived four releases and
one review that considered dropping it and declined, because nothing had
measured it. overlap_guard now does: 983 / 920 / 882 us at out-degree 0 / 666 /
2,666. Flat. Nine documentation locations corrected, and the arms are labelled
by out-degree rather than by edge count, which an earlier draft got wrong by 3x
(D-134). The real cost is O(version count per edge key), which archival caps.

One figure got worse on inspection: the 90-row edge chunk into a populated
table published 47.7 ms attributed to the missing index. That was the
pre-index measurement, left in place after the fix shipped. It is 9.06 ms
measured, missed by ~3x rather than 16x, and the residual is recorded as
unattributed (D-136).

The Python diagnostic path is bounded to one open at a time. diagnostic_query
and explain are the only methods that open the file after open() returns, and
block_on releases the GIL, so threads sharing one handle reached R15 without
ever calling open twice. 7 bad runs in 18 before, 0 in 18 after; most came back
as a returned EngineError rather than a crash (D-138). This bounds R15, it does
not fix it: the fault is upstream in libSQL 0.9.30, Database::open is
unchanged, and the Rust diagnostic_conn is documented rather than locked
because its rustdoc promises the connection is the caller's own. ATTACH was
probed alongside and inherits the read-only flags -- no back door (D-137).

Published performance claims now have a tripwire. tests/perf_claim_tests.rs,
sixteen entries and six tests, on the pattern index_plan_tests established for
indices. It asserts no number is correct -- D-055 rules that out and D-070's
session noise is why -- only that every published claim is traceable to a bench
that exists and a decision that ratified it, and that one fact is not published
as two numbers. The key is (operation, fixture, metric); the dry-run that found
`fixture` belonged in it ran before any test code (D-139). It caught its first
real drift during this release and the repair kept the key rather than
splitting it (D-141).

--all-features is no longer published as a test configuration: it puts the
R15-prone binaries back in the main run, measured 4 of 5 still red at the
six-attempt budget. The count is dropped rather than gated (D-140).

The 0.10.0 performance column in the README is measured, not carried over --
median of three sessions, controls published per group. Eight of ten rows land
within 8% of 0.9.0, which is the expected answer because no read, fold or write
path changed. Chunk commit does not fit at 2.71 ms against 2.38, from five
measurements at 1.1% spread with a normal control. Reported as measured and
attributed to nothing; it does not overturn chunk_rows::EDGES, and Appendix C
owns the reconciliation.

Suite: 340 default, 349 with metrics across 29 targets; Python 355 passed, 2
skipped. See docs/releases/v0.10.0.md.
Assets 2
Loading