notmuch/lib/query.cc, branch debian-0.1-1

lib: Rename iterator functions to prepare for reverse iteration.

2010-03-09T17:22:29Z

We rename 'has_more' to 'valid' so that it can function whether iterating in a forward or reverse direction. We also rename 'advance' to 'move_to_next' to setup parallel naming with the proposed functions 'move_to_first', 'move_to_last', and 'move_to_previous'.

lib: Explicitly set BoolWeight when searching.

2010-01-09T19:16:40Z

All notmuch searches currently sort by value (either date or message ID) so it's just wasted effort for Xapian to compute relevance values for each result. We now explicitly tell Xapian that we're uninterested in the relevance values.

Silence compiler warning by initializing a variable.

2009-11-28T02:38:06Z

If Xapian threw an exception on notmuch_query_count_messages the count variable could be used uninitialized. Initialize count to solve the problem. Signed-off-by: Jeffrey C. Ollie

lib/messages.c: Make message searches stream as well.

2009-11-24T19:33:09Z

Xapian provides an interator-based interface to all search results. So it was natural to make notmuch_messages_t be iterator-based as well. Which we did originally. But we ran into a problem when we added two APIs, (_get_replies and _get_toplevel_messages), that want to return a messages iterator that's *not* based on a Xapian search result. My original compromise was to use notmuch_message_list_t as the basis for all returned messages iterators in the public interface. This had the problem of introducing extra latency at the beginning of a search for messages, (the call would block while iterating over all results from Xapian, converting to a message list). In this commit, we remove that initial conversion and instead provide two alternate implementations of notmuch_messages_t (one on top of a Xapian iterator and one on top of a message list). With this change, I tested a "notmuch search" returning *many* results as previously taking about 7 seconds before results started appearing, and now taking only 2 seconds.

lib/query: Drop the first and max_messages arguments from search_messages.

2009-11-24T04:25:13Z

These only existed to support the chunky-searching hack, but that was recently dropped anyway.

lib/query: Fix notmuch_threads_t to stream results rather than blocking.

2009-11-24T04:18:57Z

Previously, notmuch_query_search_threads would do all the work, so the caller would block until all results were processed. Now, we do the work as we go, as the caller iterates with notmuch_threads_next. This means that once results start coming back from "notmuch search" they just keep continually streaming. There's still some initial blocking before the first results appear because the notmuch_messages_t object has the same bug (for now).

notmuch search: Remove the chunked-searching hack.

2009-11-24T04:17:37Z

This was a poor workaround around the fact that the existing notmuch_threads_t object is implemented poorly. It's got a fine iterartor-based interface, but the implementation does all of the work up-front in _create rather than doing the work incrementally while iterating. So to start fixing this, first get rid of all the hacks we had working around this. This drops the --first and --max-threads options from the search command, (but hopefully nobody was using them anyway---notmuch.el certainly wasn't).

Add 'notmuch count' command to show the count of matching messages

2009-11-23T05:33:54Z

Getting the count of matching threads or messages is a fairly expensive operation. Xapian provides a very efficient mechanism that returns an approximate value, so use that for this new command. This returns the number of matching messages, not threads, as that is cheap to compute. Signed-off-by: Keith Packard

Catch and optionally print about exception at database->flush.

2009-11-22T02:54:20Z

If an earlier exception occurred, then it's not unexpected for the flush to fail as well. So in that case, we'll silently catch the exception. Otherwise, make some noise about things going wrong at the time of flush.

Print information about where Xapian exception occurred.

2009-11-22T02:51:35Z

Previously, our Xapian exception reports where identical so they were hard to track down.