HyperCrux 0.1 came out on 6 October as a Go package and a command-line tool built on SQLite. Every record has four handles: its key, SQL, its links to other records and its vector. One transaction covers all of them, so the four can’t drift apart. The rules linking them are stored inside the file as SQLite triggers, which means a plain Python script, with no HyperCrux code at all, can write to the same file and the rules still hold.
The kill test killed a writer with SIGKILL 200 times across 30,520 transactions, and after each kill the file matched what had been committed. Ukue went through the same kind of test with its workers.
Export and Import in 0.2.0
0.2.0, released on 7 October, added hypercrux export and hypercrux import. They write a database out as JSON lines, with its tables, records and links, and read it back into a new file. The format is documented, so a backup can be read from any language. It’s also how a database moves from one HyperCrux engine to another, and a second engine is on the way.
A New Engine in Go
The bigger job is the Beta, an engine written in Go alone, without SQLite or C. It keeps one file on disk, and every process that opens the file holds its own copy of the data in memory. The plan put it at 133 hours of work in 48 tasks, and the go-ahead came on 7 October.
A week later, 44 of the tasks are done, 120 of the 133 hours, and the first working version came out of task G2. The long test runs started on 13 October. The first full run caught every planted bug on both architectures, and a fuzzer found a condition with an odd name that the parser couldn’t print back unchanged, fixed the next day. Four tasks are left: finishing the long runs, an independent review, the docs and the site, and the release run. The task board keeps a brief or a record for each task.
Meanwhile 0.x, the SQLite version, is still maintained. 0.2.0 is on the releases page.