Re: [Monotone-devel] database compaction

[Markus Schiltknecht]

Hi,

Nathaniel Smith wrote:
> The tricky part about this is the regenerate caches stuff -- revisions
> are sacrosanct, because they give "ground truth", while heights may
> get wiped out and regenerated.

So? I don't see that much of a difference between:

DELETE FROM revision_heights;

and

UPDATE revisions SET height = NULL;

Okay, internally, the revisions table might get rewritten, but that's 
standard procedure in sqlite anyway. It certainly doesn't pose any 
additional security risk to the sacrosanct revisions, does it?

> So the db needs to be able to
> represent "here are all the revisions, none of them have heights
> assigned", and we need to be able to detect when the db is in this
> state.

Uhm.. you are talking about database::check_format(), right? I've simply 
removed the heights check there... doh!  Now re-added in revision 56567b43

Note that my new check is even more restrictive than the old one:

SELECT 1 FROM heights LIMIT 1;

vs.

SELECT 1 FROM revisions WHERE height IS NULL LIMIT 1;

It does not only check if we have at least one height (and then assume 
we have all), but it checks if we miss a single height.

BTW: arguing along that line of merging heights into revisions, we 
should probably even merge rosters and roster_deltas into the revisions 
table. That would save us another column of hashes ;-)

Or maybe just merge heights, rosters and roster_deltas into one table? 
That would maintain the 'cached data in different tables' distinction 
and still save us one hash and a row header per revision - plus an index.

Regards

Markus