Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

>
> I think this makes sense, and makes me more comfortable with the overall
> idea of this patch series.  maybe it'd be useful to clearly document the
> intended scope?
>

Sure, where do you think that kind of documentation is appropriate?
There is the giant comment about the database schema in
lib/database.cc. Actually I just noticed I already failed to update that
for libconfig stuff.
>
> From elsewhere:
>
>  * for messages which have multiple files, which file is actually indexed

yes. Although rather than storing that, I think the right answer is more
like "all of them".

>  * thread-id
>  * tag
>
> we're now talking about adding properties, which are in the "elsewhere"
> category, right?

Correct.

>
> It's worth noticing that the stuff in "elsewhere" is the stuff that
> won't propagate across a dump/restore unless it's explicitly in the dump
> somehow.   We currently fail to restore thread-id and which file is
> actually indexed across a dump/restore :/

The thread-id is in some sense derived from the message itself. Not in a
reproducable way, but still, the dump file is the minimal set of extra
data needed to reconstruct an equivalent database (pax threading bugs).

> I think you've convinced me that it's good to go ahead with the
> properties, assuming it's scoped as defined above.  I still think that
> we need a better story for upgrades to the dump format in general, but
> maybe this isn't the place to make that particular case.
>
>             --dkg

I'm not sure what you have in mind, something more ambitious than the
header added post 0.22?