check performance and API's

[Andrew Bennetts]

Robert Collins wrote:
[...]
> I'm thinking that changing the vf check api to take an optional set of
> keys to check, and a checker object to provide check results to.
> 
> If not provided, all keys would be checked. Check would then return the
> same type of result as get_record_stream. The difference would be that
> check would [optionally depending on the vf type] do extra consistency
> checks.
> 
> This seems to me to permit checking of physical storage we don't look at
> on every read operation, extracting every text so we can check the
> chained sha1s downwards and avoiding duplicate work.

That sounds reasonable to me.

This is probably a bit of a tangent, but...

One question that occurs to me is what about keys that depend on other keys?
Well “depends” is a pretty loose term...

When key X has a compression parent of key Y then it's fairly clear that Y
needs to be checked before you can declare that X is ok.  You could do this
in the VF check method by just extending the keys-to-check value that was
originally passed as an arg.

A more complicated case is e.g. a revision object, which requires a
corresponding inventory object, which in turn (probably) requires some text
objects.  So the key dependencies here cross VF boundaries, and the
dependencies are at a higher semantic layer than the raw revision-text
storage.  Maybe these checks are at a different level to the ones you are
asking about in this email, though?

-Andrew.