thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.21_rc1 2015-08-13T21:52:51Z 2015-08-13T21:52:51Z Austin Clements amdragon@mit.edu 2014-10-13T06:20:01Z urn:sha1:7f57b747b95eece465d10fd0acba20cc3dd868f1 This adds a new document value that stores the revision of the last modification to message metadata, where the revision number increases monotonically with each database commit. An alternative would be to store the wall-clock time of the last modification of each message. In principle this is simpler and has the advantage that any process can determine the current timestamp without support from libnotmuch. However, even assuming a computer's clock never goes backward and ignoring clock skew in networked environments, this has a fatal flaw. Xapian uses (optimistic) snapshot isolation, which means reads can be concurrent with writes. Given this, consider the following time line with a write and two read transactions: write |-X-A--------------| read 1 |---B---| read 2 |---| The write transaction modifies message X and records the wall-clock time of the modification at A. The writer hangs around for a while and later commits its change. Read 1 is concurrent with the write, so it doesn't see the change to X. It does some query and records the wall-clock time of its results at B. Transaction read 2 later starts after the write commits and queries for changes since wall-clock time B (say the reads are performing an incremental backup). Even though read 1 could not see the change to X, read 2 is told (correctly) that X has not changed since B, the time of the last read. In fact, X changed before wall-clock time A, but the change was not visible until *after* wall-clock time B, so read 2 misses the change to X. This is tricky to solve in full-blown snapshot isolation, but because Xapian serializes writes, we can use a simple, monotonically increasing database revision number. Furthermore, maintaining this revision number requires no more IO than a wall-clock time solution because Xapian already maintains statistics on the upper (and lower) bound of each value stream. 2015-08-04T06:54:46Z Austin Clements amdragon@mit.edu 2015-06-05T17:28:33Z urn:sha1:e6ad3a5dd4ca7a09a4760c4eb6721217cc906aaa Previously, we updated the database copy of a message on every call to _notmuch_message_sync, even if nothing had changed. In particular, this always happens on a thaw, so a freeze/thaw pair with no modifications between still caused a database update. We only modify message documents in a handful of places, so keep track of whether the document has been modified and only sync it when necessary. This will be particularly important when we add message revision tracking. 2015-03-28T23:34:15Z David Bremner david@tethera.net 2014-12-26T17:34:49Z urn:sha1:9d192da683b0656e37fc8d69c69698ca605926b3 You may wonder why _notmuch_message_file_open_ctx has two parameters. This is because we need sometime to use a ctx which is a notmuch_message_t. While we could get the database from this, there is no easy way in C to tell type we are getting. 2015-03-28T23:34:15Z David Bremner david@tethera.net 2014-12-26T16:25:35Z urn:sha1:736ac26407914425a9c94e86616225292cf716dd This is not supposed to change any functionality from an end user point of view. Note that it will eliminate some output to stderr. The query debugging output is left as is; it doesn't really fit with the current primitive logging model. The remaining "bad" fprintf will need an internal API change. 2015-03-28T23:34:15Z David Bremner david@tethera.net 2014-12-26T16:16:12Z urn:sha1:9b73a8bcc9cb381fc1a15013f4baa3ec9fdb97a7 This is needed by logging in functions outside message.cc that take only a notmuch_message_t object. 2015-01-02T16:18:42Z David Bremner david@tethera.net 2015-01-02T16:18:42Z urn:sha1:105537a809d1a385a3151de0c5b6235773782040 Apparently this is a supported and even idiomatic way of keeping a temporary object (e.g. like that returned from an operator dereference) alive. 2015-01-02T16:10:37Z David Bremner david@tethera.net 2014-12-28T10:45:08Z urn:sha1:3d978a0d61df072de7e4fd52120f3448cf8e9df6 Tamas Szakaly points out [1] that the bug fixed in 51b073c still exists in at least one place. This change follows the suggestion of [2] and creates a block scope temporary std::string to avoid the rules of iterators temporaries. [1]: id:20141226113755.GA64154@pamparam [2]: id:20141226230655.GA41992@pamparam 2014-10-25T17:26:54Z Austin Clements amdragon@mit.edu 2014-10-23T12:30:36Z urn:sha1:bc9c50602d20ce712188ea2cc3c5d30647d4d3f5 This updates the message abstraction to support ghost messages: it adds a message flag that distinguishes regular messages from ghost messages, and an internal function for initializing a newly created (blank) message as a ghost message. 2014-10-25T17:26:43Z Austin Clements aclements@csail.mit.edu 2014-10-24T12:49:15Z urn:sha1:d99491f27440d83f937131a861ca547bffb8bdf1 These macros help clarify basic bit-twiddling code and are written to be robust against C undefined behavior of shift operators. 2014-10-11T05:10:12Z Austin Clements amdragon@mit.edu 2014-10-06T23:17:09Z urn:sha1:7487e2e2214b27407e542df164a4d23520bbd8d8 In the interest of robustness, avoid undefined behavior of sortable_unserialise if the date value is missing. This shouldn't happen now, but ghost messages will have blank date values.