On Fri 2016-06-03 08:54:00 -0400, David Bremner wrote: > 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. That comment seems OK, but it won't be exposed to the people who are in that middle range (python or ruby programmers but not C programmers). Do we have a place for this kind of mid-level documenation? > [ dkg wrote: ] >> * 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". I don't think we do this, do we? Is this a bug? is it tracked somewhere? >> 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). This is exactly my point -- i don't care about reproducibility of the exact numbering, but , the thread-id is *not* reproducible from the message sets. This is not only because of the ghost message leakage bug documented in T590-thread-breakage.sh, but also because threads can be joined by a message that is later removed (e.g., the "notmuch-join" script in id:87egabu5ta.fsf@alice.fifthhorseman.net ). >> 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. > > I'm not sure what you have in mind, something more ambitious than the > header added post 0.22? Can you point me to the definition for that header? i still don't understand what the batch-tag:2 part means. (sorry i haven't been keeping up with the master branch lately!) --dkg