Author: Tom Sydney Kerckhove <syd@cs-syd.eu>
Committer: Tom Sydney Kerckhove <NorfairKing@users.noreply.github.com>
Give the facts somewhere to live A rule that cannot answer from one module needs the facts of more than one, and they have to be written down somewhere between the reading and the asking. This is that somewhere: one SQLite database, one table per fact, owned by the rule that writes it. What a rule above the module level does with facts is join them, so the store is a database rather than a pile of files. The envelope tables are the ones every run writes whatever its rules are: which packages there were, which modules each was held to covering, what each module turned out to be, and which suppressions were written in it. A fact is a row rather than a keyed entry. Two instances in one module are two facts, and there is nothing to key them on that is not invented. Where the store lives is a two-constructor type rather than a path, because `:memory:` is not a file name: it is SQLite's word for having no file at all. Merging says which tables it has nowhere to put rather than dying on the first row. A store written by an executable with a rule this one lacks is a real thing, and SQLite's answer to it is `no such table`, which is a sentence about a name nobody chose from a run that has not written its report yet. The stamp is keyed on the format version, so a store merged from one written in another format shows up as a second row and the run can say so. A tool version beside it would not work: keyed on the format, a second store's row at this same format is dropped by the insert, and two versions where one is never read is a check that reads as stronger than it is. No rule uses any of this yet. The next commit adds the level a rule declares and the first rule that needs one, and it is separate because this is a thing that can be tested on its own and that is a thing that can be read on its own.