From: David Bremner <david@tethera.net>
To: Daniel Schoepe <daniel@schoepe.org>, notmuch@notmuchmail.org
Subject: Re: [PATCH 3/5] cli/count: add --lastmod
In-Reply-To: <878u9dyq2a.fsf@schoepe.localhost>
References: <1439570878-15165-1-git-send-email-david@tethera.net>
 <1439570878-15165-4-git-send-email-david@tethera.net>
 <878u9dyq2a.fsf@schoepe.localhost>
User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-pc-linux-gnu)
Date: Sat, 15 Aug 2015 12:42:31 +0200
Message-ID: <87si7kx27c.fsf@maritornes.cs.unb.ca>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

Daniel Schoepe <daniel@schoepe.org> writes:

> Sorry to keep harping on this, but I'm not entirely happy with the way
> we handle notmuch-compact here (and in the other commit that mentions
> compacting explicitly). Given that lastmod values (and pretty much
> everything else) aren't affected by compacting, would it perhaps make
> sense to copy the previous UUID to the newly compacted database?

We aren't currently maintaining a UUID for notmuch, but using
Xapian::database::get_uuid(). There is no way in Xapian to change the
UUID; even if there was, lying to Xapian probably would not be a good
idea.

We could maintain our own UUID, but I'm not sure it's worth the extra
code just to make compaction slightly nicer. 

For me compaction is a rare event, so having to take the fallback path
and do a full dump or whatever doesn't seem so bad. If you don't want to
have a fallback path, then I guess you need to guarantee externally that
no "bad changes" happen and either ignore the uuid's or copy them
forward in your external tool.

Mainly though I think this will be fixed in Xapian. As it happens Xapian
developer Olly Betts is here at DebConf, and I discussed this problem
with him. According to Olly, in-progress / future versions of compact
will function in place, and guarantee the UUID is preserved. I'm not
sure of the timeline here, but given our scarce developer resources, I
think I'd rather wait for Olly to fix this.

On the bright side, if in the future we decide that notmuch should have
it's own notion of UUID, then this would would not change the library
API or command line interface.  There is some argument here for giving
our name to the UUID, but "revision" turned out to be a terribly
confusing choice in previous rounds of patches.  The current transparent
naming has the advantage of matching the output.

d