notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
/* database.cc - The database interfaces of the notmuch mail library
|
|
|
|
*
|
|
|
|
* Copyright © 2009 Carl Worth
|
|
|
|
*
|
|
|
|
* This program is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation, either version 3 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2016-06-02 18:26:14 +02:00
|
|
|
* along with this program. If not, see https://www.gnu.org/licenses/ .
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
*
|
|
|
|
* Author: Carl Worth <cworth@cworth.org>
|
|
|
|
*/
|
|
|
|
|
2009-10-21 06:03:30 +02:00
|
|
|
#include "database-private.h"
|
lib: add date range query support
Add a custom value range processor to enable date and time searches of
the form date:since..until, where "since" and "until" are expressions
understood by the previously added date/time parser, to restrict the
results to messages within a particular time range (based on the Date:
header).
If "since" or "until" describes date/time at an accuracy of days or
less, the values are rounded according to the accuracy, towards past
for "since" and towards future for "until". For example,
date:november..yesterday would match from the beginning of November
until the end of yesterday. Expressions such as date:today..today
means since the beginning of today until the end of today.
Open-ended ranges are supported (since Xapian 1.2.1), i.e. you can
specify date:..until or date:since.. to not limit the start or end
date, respectively.
CAVEATS:
Xapian does not support spaces in range expressions. You can replace
the spaces with '_', or (in most cases) '-', or (in some cases) leave
the spaces out altogether.
Entering date:expr without ".." (for example date:yesterday) will not
work as you might expect. You can achieve the expected result by
duplicating the expr both sides of ".." (for example
date:yesterday..yesterday).
Open-ended ranges won't work with pre-1.2.1 Xapian, but they don't
produce an error either.
Signed-off-by: Jani Nikula <jani@nikula.org>
2012-10-30 21:32:37 +01:00
|
|
|
#include "parse-time-vrp.h"
|
2016-03-22 11:54:54 +01:00
|
|
|
#include "query-fp.h"
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
#include "string-util.h"
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
#include <iostream>
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
#include <sys/time.h>
|
2013-10-02 22:30:46 +02:00
|
|
|
#include <sys/stat.h>
|
2010-01-08 03:26:31 +01:00
|
|
|
#include <signal.h>
|
2013-10-02 22:30:46 +02:00
|
|
|
#include <ftw.h>
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
#include <glib.h> /* g_free, GPtrArray, GHashTable */
|
2011-12-04 20:20:39 +01:00
|
|
|
#include <glib-object.h> /* g_type_init */
|
2009-10-19 21:54:40 +02:00
|
|
|
|
2011-12-31 05:37:41 +01:00
|
|
|
#include <gmime/gmime.h> /* g_mime_init */
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
using namespace std;
|
|
|
|
|
2009-10-25 05:52:48 +01:00
|
|
|
#define ARRAY_SIZE(arr) (sizeof (arr) / sizeof (arr[0]))
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
const char *name;
|
|
|
|
const char *prefix;
|
2017-02-17 04:07:49 +01:00
|
|
|
notmuch_field_flag_t flags;
|
2009-10-25 05:52:48 +01:00
|
|
|
} prefix_t;
|
|
|
|
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
#define NOTMUCH_DATABASE_VERSION 3
|
2010-01-08 03:26:31 +01:00
|
|
|
|
|
|
|
#define STRINGIFY(s) _SUB_STRINGIFY(s)
|
|
|
|
#define _SUB_STRINGIFY(s) #s
|
|
|
|
|
2016-06-26 17:29:43 +02:00
|
|
|
#if HAVE_XAPIAN_DB_RETRY_LOCK
|
|
|
|
#define DB_ACTION (Xapian::DB_CREATE_OR_OPEN | Xapian::DB_RETRY_LOCK)
|
|
|
|
#else
|
|
|
|
#define DB_ACTION Xapian::DB_CREATE_OR_OPEN
|
|
|
|
#endif
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
/* Here's the current schema for our database (for NOTMUCH_DATABASE_VERSION):
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2014-10-23 14:30:34 +02:00
|
|
|
* We currently have three different types of documents (mail, ghost,
|
|
|
|
* and directory) and also some metadata.
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
|
|
|
* Mail document
|
|
|
|
* -------------
|
2014-08-01 04:59:13 +02:00
|
|
|
* A mail document is associated with a particular email message. It
|
|
|
|
* is stored in one or more files on disk (though only one has its
|
|
|
|
* content indexed) and is uniquely identified by its "id" field
|
|
|
|
* (which is generally the message ID). It is indexed with the
|
|
|
|
* following prefixed terms which the database uses to construct
|
|
|
|
* threads, etc.:
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
|
|
|
* Single terms of given prefix:
|
|
|
|
*
|
|
|
|
* type: mail
|
|
|
|
*
|
2010-06-04 21:39:36 +02:00
|
|
|
* id: Unique ID of mail. This is from the Message-ID header
|
|
|
|
* if present and not too long (see NOTMUCH_MESSAGE_ID_MAX).
|
|
|
|
* If it's present and too long, then we use
|
|
|
|
* "notmuch-sha1-<sha1_sum_of_message_id>".
|
|
|
|
* If this header is not present, we use
|
|
|
|
* "notmuch-sha1-<sha1_sum_of_entire_file>".
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2009-10-25 22:54:13 +01:00
|
|
|
* thread: The ID of the thread to which the mail belongs
|
|
|
|
*
|
2009-11-18 03:48:38 +01:00
|
|
|
* replyto: The ID from the In-Reply-To header of the mail (if any).
|
|
|
|
*
|
2009-10-25 16:57:09 +01:00
|
|
|
* Multiple terms of given prefix:
|
|
|
|
*
|
2011-06-20 22:14:21 +02:00
|
|
|
* reference: All message IDs from In-Reply-To and References
|
2009-11-18 03:44:02 +01:00
|
|
|
* headers in the message.
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2009-11-18 03:44:02 +01:00
|
|
|
* tag: Any tags associated with this message by the user.
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2010-01-05 22:29:23 +01:00
|
|
|
* file-direntry: A colon-separated pair of values
|
|
|
|
* (INTEGER:STRING), where INTEGER is the
|
|
|
|
* document ID of a directory document, and
|
|
|
|
* STRING is the name of a file within that
|
|
|
|
* directory for this mail message.
|
2009-12-21 17:23:26 +01:00
|
|
|
*
|
2016-07-08 11:15:36 +02:00
|
|
|
* property: Has a property with key=value
|
|
|
|
* FIXME: if no = is present, should match on any value
|
|
|
|
*
|
2011-12-13 18:11:41 +01:00
|
|
|
* A mail document also has four values:
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
|
|
|
* TIMESTAMP: The time_t value corresponding to the message's
|
|
|
|
* Date header.
|
|
|
|
*
|
|
|
|
* MESSAGE_ID: The unique ID of the mail mess (see "id" above)
|
|
|
|
*
|
2011-12-13 18:11:41 +01:00
|
|
|
* FROM: The value of the "From" header
|
|
|
|
*
|
|
|
|
* SUBJECT: The value of the "Subject" header
|
|
|
|
*
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
* LAST_MOD: The revision number as of the last tag or
|
|
|
|
* filename change.
|
|
|
|
*
|
2009-11-18 03:48:38 +01:00
|
|
|
* In addition, terms from the content of the message are added with
|
|
|
|
* "from", "to", "attachment", and "subject" prefixes for use by the
|
2011-01-15 23:09:04 +01:00
|
|
|
* user in searching. Similarly, terms from the path of the mail
|
2014-02-08 19:50:44 +01:00
|
|
|
* message are added with "folder" and "path" prefixes. But the
|
|
|
|
* database doesn't really care itself about any of these.
|
2009-11-18 03:48:38 +01:00
|
|
|
*
|
2009-12-21 17:23:26 +01:00
|
|
|
* The data portion of a mail document is empty.
|
2009-12-19 22:05:06 +01:00
|
|
|
*
|
2014-10-23 14:30:34 +02:00
|
|
|
* Ghost mail document [if NOTMUCH_FEATURE_GHOSTS]
|
|
|
|
* -----------------------------------------------
|
|
|
|
* A ghost mail document is like a mail document, but where we don't
|
|
|
|
* have the message content. These are used to track thread reference
|
|
|
|
* information for messages we haven't received.
|
|
|
|
*
|
|
|
|
* A ghost mail document has type: ghost; id and thread fields that
|
|
|
|
* are identical to the mail document fields; and a MESSAGE_ID value.
|
|
|
|
*
|
2009-12-17 23:33:34 +01:00
|
|
|
* Directory document
|
2009-10-25 16:57:09 +01:00
|
|
|
* ------------------
|
2009-12-17 23:33:34 +01:00
|
|
|
* A directory document is used by a client of the notmuch library to
|
2009-10-25 16:57:09 +01:00
|
|
|
* maintain data necessary to allow for efficient polling of mail
|
2009-12-17 23:33:34 +01:00
|
|
|
* directories.
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2010-01-05 22:29:23 +01:00
|
|
|
* All directory documents contain one term:
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2009-12-19 22:11:00 +01:00
|
|
|
* directory: The directory path (relative to the database path)
|
2009-12-21 00:46:41 +01:00
|
|
|
* Or the SHA1 sum of the directory path (if the
|
|
|
|
* path itself is too long to fit in a Xapian
|
|
|
|
* term).
|
|
|
|
*
|
2010-01-05 22:29:23 +01:00
|
|
|
* And all directory documents for directories other than top-level
|
|
|
|
* directories also contain the following term:
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2010-01-05 22:29:23 +01:00
|
|
|
* directory-direntry: A colon-separated pair of values
|
|
|
|
* (INTEGER:STRING), where INTEGER is the
|
|
|
|
* document ID of the parent directory
|
|
|
|
* document, and STRING is the name of this
|
|
|
|
* directory within that parent.
|
|
|
|
*
|
|
|
|
* All directory documents have a single value:
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2009-12-17 23:33:34 +01:00
|
|
|
* TIMESTAMP: The mtime of the directory (at last scan)
|
2009-12-21 00:46:41 +01:00
|
|
|
*
|
|
|
|
* The data portion of a directory document contains the path of the
|
2010-01-05 22:29:23 +01:00
|
|
|
* directory (relative to the database path).
|
2010-04-13 00:15:14 +02:00
|
|
|
*
|
|
|
|
* Database metadata
|
|
|
|
* -----------------
|
|
|
|
* Xapian allows us to store arbitrary name-value pairs as
|
|
|
|
* "metadata". We currently use the following metadata names with the
|
|
|
|
* given meanings:
|
|
|
|
*
|
|
|
|
* version The database schema version, (which is distinct
|
|
|
|
* from both the notmuch package version (see
|
|
|
|
* notmuch --version) and the libnotmuch library
|
|
|
|
* version. The version is stored as an base-10
|
|
|
|
* ASCII integer. The initial database version
|
|
|
|
* was 1, (though a schema existed before that
|
|
|
|
* were no "version" database value existed at
|
2011-06-20 22:14:21 +02:00
|
|
|
* all). Successive versions are allocated as
|
2010-04-13 00:15:14 +02:00
|
|
|
* changes are made to the database (such as by
|
|
|
|
* indexing new fields).
|
|
|
|
*
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
* features The set of features supported by this
|
|
|
|
* database. This consists of a set of
|
|
|
|
* '\n'-separated lines, where each is a feature
|
|
|
|
* name, a '\t', and compatibility flags. If the
|
|
|
|
* compatibility flags contain 'w', then the
|
|
|
|
* opener must support this feature to safely
|
|
|
|
* write this database. If the compatibility
|
|
|
|
* flags contain 'r', then the opener must
|
|
|
|
* support this feature to read this database.
|
|
|
|
* Introduced in database version 3.
|
|
|
|
*
|
2010-04-13 00:15:14 +02:00
|
|
|
* last_thread_id The last thread ID generated. This is stored
|
|
|
|
* as a 16-byte hexadecimal ASCII representation
|
|
|
|
* of a 64-bit unsigned integer. The first ID
|
|
|
|
* generated is 1 and the value will be
|
|
|
|
* incremented for each thread ID.
|
|
|
|
*
|
2016-06-05 00:17:41 +02:00
|
|
|
* C* metadata keys starting with C indicate
|
|
|
|
* configuration data. It can be managed with the
|
|
|
|
* n_database_*config* API. There is a convention
|
|
|
|
* of hierarchical keys separated by '.' (e.g.
|
|
|
|
* query.notmuch stores the value for the named
|
|
|
|
* query 'notmuch'), but it is not enforced by the
|
|
|
|
* API.
|
|
|
|
*
|
2014-10-23 14:30:34 +02:00
|
|
|
* Obsolete metadata
|
|
|
|
* -----------------
|
|
|
|
*
|
|
|
|
* If ! NOTMUCH_FEATURE_GHOSTS, there are no ghost mail documents.
|
|
|
|
* Instead, the database has the following additional database
|
|
|
|
* metadata:
|
|
|
|
*
|
2010-04-13 00:15:14 +02:00
|
|
|
* thread_id_* A pre-allocated thread ID for a particular
|
2011-06-20 22:14:21 +02:00
|
|
|
* message. This is actually an arbitrarily large
|
2010-06-04 21:39:36 +02:00
|
|
|
* family of metadata name. Any particular name is
|
|
|
|
* formed by concatenating "thread_id_" with a message
|
|
|
|
* ID (or the SHA1 sum of a message ID if it is very
|
|
|
|
* long---see description of 'id' in the mail
|
|
|
|
* document). The value stored is a thread ID.
|
2010-04-13 00:15:14 +02:00
|
|
|
*
|
|
|
|
* These thread ID metadata values are stored
|
|
|
|
* whenever a message references a parent message
|
|
|
|
* that does not yet exist in the database. A
|
|
|
|
* thread ID will be allocated and stored, and if
|
|
|
|
* the message is later added, the stored thread
|
|
|
|
* ID will be used (and the metadata value will
|
|
|
|
* be cleared).
|
|
|
|
*
|
|
|
|
* Even before a message is added, it's
|
|
|
|
* pre-allocated thread ID is useful so that all
|
|
|
|
* descendant messages that reference this common
|
|
|
|
* parent can be recognized as belonging to the
|
|
|
|
* same thread.
|
2009-10-25 16:57:09 +01:00
|
|
|
*/
|
|
|
|
|
2009-10-25 06:49:35 +01:00
|
|
|
/* With these prefix values we follow the conventions published here:
|
|
|
|
*
|
2016-06-02 18:26:14 +02:00
|
|
|
* https://xapian.org/docs/omega/termprefixes.html
|
2009-10-25 06:49:35 +01:00
|
|
|
*
|
|
|
|
* as much as makes sense. Note that I took some liberty in matching
|
|
|
|
* the reserved prefix values to notmuch concepts, (for example, 'G'
|
|
|
|
* is documented as "newsGroup (or similar entity - e.g. a web forum
|
|
|
|
* name)", for which I think the thread is the closest analogue in
|
|
|
|
* notmuch. This in spite of the fact that we will eventually be
|
|
|
|
* storing mailing-list messages where 'G' for "mailing list name"
|
|
|
|
* might be even a closer analogue. I'm treating the single-character
|
|
|
|
* prefixes preferentially for core notmuch concepts (which will be
|
|
|
|
* nearly universal to all mail messages).
|
|
|
|
*/
|
|
|
|
|
2017-02-17 04:07:49 +01:00
|
|
|
static const
|
|
|
|
prefix_t prefix_table[] = {
|
|
|
|
/* name term prefix flags */
|
|
|
|
{ "type", "T", NOTMUCH_FIELD_NO_FLAGS },
|
|
|
|
{ "reference", "XREFERENCE", NOTMUCH_FIELD_NO_FLAGS },
|
|
|
|
{ "replyto", "XREPLYTO", NOTMUCH_FIELD_NO_FLAGS },
|
|
|
|
{ "directory", "XDIRECTORY", NOTMUCH_FIELD_NO_FLAGS },
|
|
|
|
{ "file-direntry", "XFDIRENTRY", NOTMUCH_FIELD_NO_FLAGS },
|
|
|
|
{ "directory-direntry", "XDDIRENTRY", NOTMUCH_FIELD_NO_FLAGS },
|
|
|
|
{ "thread", "G", NOTMUCH_FIELD_EXTERNAL },
|
|
|
|
{ "tag", "K", NOTMUCH_FIELD_EXTERNAL },
|
|
|
|
{ "is", "K", NOTMUCH_FIELD_EXTERNAL },
|
|
|
|
{ "id", "Q", NOTMUCH_FIELD_EXTERNAL },
|
|
|
|
{ "path", "P", NOTMUCH_FIELD_EXTERNAL },
|
|
|
|
{ "property", "XPROPERTY", NOTMUCH_FIELD_EXTERNAL },
|
2014-02-08 20:20:42 +01:00
|
|
|
/*
|
2016-08-18 10:06:54 +02:00
|
|
|
* Unconditionally add ':' to reduce potential ambiguity with
|
|
|
|
* overlapping prefixes and/or terms that start with capital
|
|
|
|
* letters. See Xapian document termprefixes.html for related
|
|
|
|
* discussion.
|
2014-02-08 20:20:42 +01:00
|
|
|
*/
|
2017-02-17 04:07:49 +01:00
|
|
|
{ "folder", "XFOLDER:", NOTMUCH_FIELD_EXTERNAL },
|
|
|
|
{ "from", "XFROM", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROBABILISTIC },
|
|
|
|
{ "to", "XTO", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROBABILISTIC },
|
|
|
|
{ "attachment", "XATTACHMENT", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROBABILISTIC },
|
|
|
|
{ "mimetype", "XMIMETYPE", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROBABILISTIC },
|
|
|
|
{ "subject", "XSUBJECT", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROBABILISTIC },
|
2009-10-28 18:42:07 +01:00
|
|
|
};
|
|
|
|
|
2009-10-25 05:52:48 +01:00
|
|
|
const char *
|
|
|
|
_find_prefix (const char *name)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
2017-02-17 04:07:49 +01:00
|
|
|
for (i = 0; i < ARRAY_SIZE (prefix_table); i++) {
|
|
|
|
if (strcmp (name, prefix_table[i].name) == 0)
|
|
|
|
return prefix_table[i].prefix;
|
2009-11-22 00:14:39 +01:00
|
|
|
}
|
2009-10-28 18:42:07 +01:00
|
|
|
|
2009-10-25 18:22:41 +01:00
|
|
|
INTERNAL_ERROR ("No prefix exists for '%s'\n", name);
|
2009-10-25 05:52:48 +01:00
|
|
|
|
|
|
|
return "";
|
|
|
|
}
|
|
|
|
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
static const struct {
|
|
|
|
/* NOTMUCH_FEATURE_* value. */
|
|
|
|
_notmuch_features value;
|
|
|
|
/* Feature name as it appears in the database. This name should
|
|
|
|
* be appropriate for displaying to the user if an older version
|
|
|
|
* of notmuch doesn't support this feature. */
|
|
|
|
const char *name;
|
|
|
|
/* Compatibility flags when this feature is declared. */
|
|
|
|
const char *flags;
|
|
|
|
} feature_names[] = {
|
|
|
|
{ NOTMUCH_FEATURE_FILE_TERMS,
|
|
|
|
"multiple paths per message", "rw" },
|
|
|
|
{ NOTMUCH_FEATURE_DIRECTORY_DOCS,
|
|
|
|
"relative directory paths", "rw" },
|
|
|
|
/* Header values are not required for reading a database because a
|
|
|
|
* reader can just refer to the message file. */
|
|
|
|
{ NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES,
|
|
|
|
"from/subject/message-ID in database", "w" },
|
|
|
|
{ NOTMUCH_FEATURE_BOOL_FOLDER,
|
|
|
|
"exact folder:/path: search", "rw" },
|
2014-10-23 14:30:33 +02:00
|
|
|
{ NOTMUCH_FEATURE_GHOSTS,
|
|
|
|
"mail documents for missing messages", "w"},
|
2015-01-23 00:43:37 +01:00
|
|
|
/* Knowledge of the index mime-types are not required for reading
|
|
|
|
* a database because a reader will just be unable to query
|
|
|
|
* them. */
|
|
|
|
{ NOTMUCH_FEATURE_INDEXED_MIMETYPES,
|
|
|
|
"indexed MIME types", "w"},
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
{ NOTMUCH_FEATURE_LAST_MOD,
|
|
|
|
"modification tracking", "w"},
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
};
|
|
|
|
|
2009-10-22 01:12:53 +02:00
|
|
|
const char *
|
|
|
|
notmuch_status_to_string (notmuch_status_t status)
|
|
|
|
{
|
|
|
|
switch (status) {
|
|
|
|
case NOTMUCH_STATUS_SUCCESS:
|
|
|
|
return "No error occurred";
|
2009-10-26 00:03:45 +01:00
|
|
|
case NOTMUCH_STATUS_OUT_OF_MEMORY:
|
|
|
|
return "Out of memory";
|
2010-01-07 19:29:05 +01:00
|
|
|
case NOTMUCH_STATUS_READ_ONLY_DATABASE:
|
2010-01-06 00:01:58 +01:00
|
|
|
return "Attempt to write to a read-only database";
|
2009-10-22 01:12:53 +02:00
|
|
|
case NOTMUCH_STATUS_XAPIAN_EXCEPTION:
|
|
|
|
return "A Xapian exception occurred";
|
2009-10-23 00:31:56 +02:00
|
|
|
case NOTMUCH_STATUS_FILE_ERROR:
|
|
|
|
return "Something went wrong trying to read or write a file";
|
2009-10-22 01:12:53 +02:00
|
|
|
case NOTMUCH_STATUS_FILE_NOT_EMAIL:
|
|
|
|
return "File is not an email";
|
2009-10-23 23:40:33 +02:00
|
|
|
case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
|
|
|
|
return "Message ID is identical to a message in database";
|
2009-10-22 01:12:53 +02:00
|
|
|
case NOTMUCH_STATUS_NULL_POINTER:
|
|
|
|
return "Erroneous NULL pointer";
|
|
|
|
case NOTMUCH_STATUS_TAG_TOO_LONG:
|
2009-10-23 23:34:21 +02:00
|
|
|
return "Tag value is too long (exceeds NOTMUCH_TAG_MAX)";
|
2009-10-27 06:25:45 +01:00
|
|
|
case NOTMUCH_STATUS_UNBALANCED_FREEZE_THAW:
|
2009-11-18 00:23:42 +01:00
|
|
|
return "Unbalanced number of calls to notmuch_message_freeze/thaw";
|
2011-06-11 05:35:06 +02:00
|
|
|
case NOTMUCH_STATUS_UNBALANCED_ATOMIC:
|
|
|
|
return "Unbalanced number of calls to notmuch_database_begin_atomic/end_atomic";
|
2013-10-02 22:30:46 +02:00
|
|
|
case NOTMUCH_STATUS_UNSUPPORTED_OPERATION:
|
|
|
|
return "Unsupported operation";
|
2014-08-25 19:26:08 +02:00
|
|
|
case NOTMUCH_STATUS_UPGRADE_REQUIRED:
|
|
|
|
return "Operation requires a database upgrade";
|
2015-06-10 07:58:44 +02:00
|
|
|
case NOTMUCH_STATUS_PATH_ERROR:
|
|
|
|
return "Path supplied is illegal for this function";
|
2009-10-22 01:12:53 +02:00
|
|
|
default:
|
|
|
|
case NOTMUCH_STATUS_LAST_STATUS:
|
|
|
|
return "Unknown error status value";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-26 09:01:01 +01:00
|
|
|
void
|
|
|
|
_notmuch_database_log (notmuch_database_t *notmuch,
|
|
|
|
const char *format,
|
|
|
|
...)
|
|
|
|
{
|
|
|
|
va_list va_args;
|
|
|
|
|
|
|
|
va_start (va_args, format);
|
|
|
|
|
|
|
|
if (notmuch->status_string)
|
|
|
|
talloc_free (notmuch->status_string);
|
|
|
|
|
|
|
|
notmuch->status_string = talloc_vasprintf (notmuch, format, va_args);
|
2016-07-15 12:25:41 +02:00
|
|
|
va_end (va_args);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
_notmuch_database_log_append (notmuch_database_t *notmuch,
|
|
|
|
const char *format,
|
|
|
|
...)
|
|
|
|
{
|
|
|
|
va_list va_args;
|
|
|
|
|
|
|
|
va_start (va_args, format);
|
|
|
|
|
|
|
|
if (notmuch->status_string)
|
|
|
|
notmuch->status_string = talloc_vasprintf_append (notmuch->status_string, format, va_args);
|
|
|
|
else
|
|
|
|
notmuch->status_string = talloc_vasprintf (notmuch, format, va_args);
|
2014-12-26 09:01:01 +01:00
|
|
|
|
|
|
|
va_end (va_args);
|
|
|
|
}
|
|
|
|
|
2009-12-22 00:12:52 +01:00
|
|
|
static void
|
|
|
|
find_doc_ids_for_term (notmuch_database_t *notmuch,
|
|
|
|
const char *term,
|
|
|
|
Xapian::PostingIterator *begin,
|
|
|
|
Xapian::PostingIterator *end)
|
|
|
|
{
|
|
|
|
*begin = notmuch->xapian_db->postlist_begin (term);
|
|
|
|
|
|
|
|
*end = notmuch->xapian_db->postlist_end (term);
|
|
|
|
}
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
static void
|
2009-10-23 23:06:24 +02:00
|
|
|
find_doc_ids (notmuch_database_t *notmuch,
|
|
|
|
const char *prefix_name,
|
|
|
|
const char *value,
|
|
|
|
Xapian::PostingIterator *begin,
|
|
|
|
Xapian::PostingIterator *end)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
|
|
|
char *term;
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
term = talloc_asprintf (notmuch, "%s%s",
|
|
|
|
_find_prefix (prefix_name), value);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-12-22 00:12:52 +01:00
|
|
|
find_doc_ids_for_term (notmuch, term, begin, end);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
talloc_free (term);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2010-01-05 22:29:23 +01:00
|
|
|
notmuch_private_status_t
|
|
|
|
_notmuch_database_find_unique_doc_id (notmuch_database_t *notmuch,
|
|
|
|
const char *prefix_name,
|
|
|
|
const char *value,
|
|
|
|
unsigned int *doc_id)
|
2009-10-23 23:24:07 +02:00
|
|
|
{
|
|
|
|
Xapian::PostingIterator i, end;
|
|
|
|
|
|
|
|
find_doc_ids (notmuch, prefix_name, value, &i, &end);
|
|
|
|
|
|
|
|
if (i == end) {
|
|
|
|
*doc_id = 0;
|
|
|
|
return NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND;
|
|
|
|
}
|
2009-12-22 00:11:32 +01:00
|
|
|
|
|
|
|
*doc_id = *i;
|
|
|
|
|
|
|
|
#if DEBUG_DATABASE_SANITY
|
|
|
|
i++;
|
|
|
|
|
|
|
|
if (i != end)
|
|
|
|
INTERNAL_ERROR ("Term %s:%s is not unique as expected.\n",
|
|
|
|
prefix_name, value);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return NOTMUCH_PRIVATE_STATUS_SUCCESS;
|
2009-10-23 23:24:07 +02:00
|
|
|
}
|
|
|
|
|
2009-10-23 23:12:06 +02:00
|
|
|
static Xapian::Document
|
|
|
|
find_document_for_doc_id (notmuch_database_t *notmuch, unsigned doc_id)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2009-10-23 23:12:06 +02:00
|
|
|
return notmuch->xapian_db->get_document (doc_id);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2010-06-04 21:39:36 +02:00
|
|
|
/* Generate a compressed version of 'message_id' of the form:
|
|
|
|
*
|
|
|
|
* notmuch-sha1-<sha1_sum_of_message_id>
|
|
|
|
*/
|
2014-10-07 01:17:07 +02:00
|
|
|
char *
|
|
|
|
_notmuch_message_id_compressed (void *ctx, const char *message_id)
|
2010-06-04 21:39:36 +02:00
|
|
|
{
|
|
|
|
char *sha1, *compressed;
|
|
|
|
|
2014-05-13 11:44:05 +02:00
|
|
|
sha1 = _notmuch_sha1_of_string (message_id);
|
2010-06-04 21:39:36 +02:00
|
|
|
|
|
|
|
compressed = talloc_asprintf (ctx, "notmuch-sha1-%s", sha1);
|
|
|
|
free (sha1);
|
|
|
|
|
|
|
|
return compressed;
|
|
|
|
}
|
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
notmuch_status_t
|
2009-10-22 00:37:51 +02:00
|
|
|
notmuch_database_find_message (notmuch_database_t *notmuch,
|
2011-10-04 06:55:29 +02:00
|
|
|
const char *message_id,
|
|
|
|
notmuch_message_t **message_ret)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2009-10-23 23:24:07 +02:00
|
|
|
notmuch_private_status_t status;
|
|
|
|
unsigned int doc_id;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
if (message_ret == NULL)
|
|
|
|
return NOTMUCH_STATUS_NULL_POINTER;
|
|
|
|
|
2010-06-04 21:39:36 +02:00
|
|
|
if (strlen (message_id) > NOTMUCH_MESSAGE_ID_MAX)
|
2014-10-07 01:17:07 +02:00
|
|
|
message_id = _notmuch_message_id_compressed (notmuch, message_id);
|
2010-06-04 21:39:36 +02:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
try {
|
|
|
|
status = _notmuch_database_find_unique_doc_id (notmuch, "id",
|
|
|
|
message_id, &doc_id);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
if (status == NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND)
|
2011-10-04 06:55:29 +02:00
|
|
|
*message_ret = NULL;
|
|
|
|
else {
|
|
|
|
*message_ret = _notmuch_message_create (notmuch, notmuch, doc_id,
|
|
|
|
NULL);
|
|
|
|
if (*message_ret == NULL)
|
|
|
|
return NOTMUCH_STATUS_OUT_OF_MEMORY;
|
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
2010-04-24 16:22:34 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "A Xapian exception occurred finding message: %s.\n",
|
2010-04-24 16:22:34 +02:00
|
|
|
error.get_msg().c_str());
|
|
|
|
notmuch->exception_reported = TRUE;
|
2011-10-04 06:55:29 +02:00
|
|
|
*message_ret = NULL;
|
|
|
|
return NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
2010-04-24 16:22:34 +02:00
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
/* Advance 'str' past any whitespace or RFC 822 comments. A comment is
|
|
|
|
* a (potentially nested) parenthesized sequence with '\' used to
|
|
|
|
* escape any character (including parentheses).
|
|
|
|
*
|
|
|
|
* If the sequence to be skipped continues to the end of the string,
|
|
|
|
* then 'str' will be left pointing at the final terminating '\0'
|
|
|
|
* character.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
skip_space_and_comments (const char **str)
|
|
|
|
{
|
|
|
|
const char *s;
|
|
|
|
|
|
|
|
s = *str;
|
|
|
|
while (*s && (isspace (*s) || *s == '(')) {
|
|
|
|
while (*s && isspace (*s))
|
|
|
|
s++;
|
|
|
|
if (*s == '(') {
|
|
|
|
int nesting = 1;
|
|
|
|
s++;
|
|
|
|
while (*s && nesting) {
|
2009-11-22 00:14:39 +01:00
|
|
|
if (*s == '(') {
|
2009-10-19 21:54:40 +02:00
|
|
|
nesting++;
|
2009-11-22 00:14:39 +01:00
|
|
|
} else if (*s == ')') {
|
2009-10-19 21:54:40 +02:00
|
|
|
nesting--;
|
2009-11-22 00:14:39 +01:00
|
|
|
} else if (*s == '\\') {
|
2009-10-19 21:54:40 +02:00
|
|
|
if (*(s+1))
|
|
|
|
s++;
|
2009-11-22 00:14:39 +01:00
|
|
|
}
|
2009-10-19 21:54:40 +02:00
|
|
|
s++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
*str = s;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse an RFC 822 message-id, discarding whitespace, any RFC 822
|
2011-06-20 22:14:21 +02:00
|
|
|
* comments, and the '<' and '>' delimiters.
|
2009-10-19 21:54:40 +02:00
|
|
|
*
|
|
|
|
* If not NULL, then *next will be made to point to the first character
|
|
|
|
* not parsed, (possibly pointing to the final '\0' terminator.
|
|
|
|
*
|
2009-10-26 23:17:10 +01:00
|
|
|
* Returns a newly talloc'ed string belonging to 'ctx'.
|
2009-10-19 21:54:40 +02:00
|
|
|
*
|
|
|
|
* Returns NULL if there is any error parsing the message-id. */
|
2009-11-18 03:50:13 +01:00
|
|
|
static char *
|
2009-11-16 05:21:43 +01:00
|
|
|
_parse_message_id (void *ctx, const char *message_id, const char **next)
|
2009-10-19 21:54:40 +02:00
|
|
|
{
|
|
|
|
const char *s, *end;
|
2009-10-21 19:07:34 +02:00
|
|
|
char *result;
|
2009-10-19 21:54:40 +02:00
|
|
|
|
2009-11-20 21:46:37 +01:00
|
|
|
if (message_id == NULL || *message_id == '\0')
|
2009-10-19 21:54:40 +02:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
s = message_id;
|
|
|
|
|
|
|
|
skip_space_and_comments (&s);
|
|
|
|
|
|
|
|
/* Skip any unstructured text as well. */
|
|
|
|
while (*s && *s != '<')
|
|
|
|
s++;
|
|
|
|
|
|
|
|
if (*s == '<') {
|
|
|
|
s++;
|
|
|
|
} else {
|
|
|
|
if (next)
|
|
|
|
*next = s;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
skip_space_and_comments (&s);
|
|
|
|
|
|
|
|
end = s;
|
|
|
|
while (*end && *end != '>')
|
|
|
|
end++;
|
|
|
|
if (next) {
|
|
|
|
if (*end)
|
|
|
|
*next = end + 1;
|
|
|
|
else
|
|
|
|
*next = end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (end > s && *end == '>')
|
|
|
|
end--;
|
2009-10-21 19:07:34 +02:00
|
|
|
if (end <= s)
|
2009-10-19 21:54:40 +02:00
|
|
|
return NULL;
|
2009-10-21 19:07:34 +02:00
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
result = talloc_strndup (ctx, s, end - s + 1);
|
2009-10-21 19:07:34 +02:00
|
|
|
|
|
|
|
/* Finally, collapse any whitespace that is within the message-id
|
|
|
|
* itself. */
|
|
|
|
{
|
|
|
|
char *r;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
for (r = result, len = strlen (r); *r; r++, len--)
|
|
|
|
if (*r == ' ' || *r == '\t')
|
|
|
|
memmove (r, r+1, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
2009-10-19 21:54:40 +02:00
|
|
|
}
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
/* Parse a References header value, putting a (talloc'ed under 'ctx')
|
2009-11-18 02:20:32 +01:00
|
|
|
* copy of each referenced message-id into 'hash'.
|
|
|
|
*
|
|
|
|
* We explicitly avoid including any reference identical to
|
|
|
|
* 'message_id' in the result (to avoid mass confusion when a single
|
|
|
|
* message references itself cyclically---and yes, mail messages are
|
|
|
|
* not infrequent in the wild that do this---don't ask me why).
|
2013-03-06 04:31:49 +01:00
|
|
|
*
|
|
|
|
* Return the last reference parsed, if it is not equal to message_id.
|
|
|
|
*/
|
|
|
|
static char *
|
2009-10-26 23:17:10 +01:00
|
|
|
parse_references (void *ctx,
|
2009-11-18 02:20:32 +01:00
|
|
|
const char *message_id,
|
2009-10-26 23:17:10 +01:00
|
|
|
GHashTable *hash,
|
2009-10-19 21:54:40 +02:00
|
|
|
const char *refs)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2014-05-26 16:05:57 +02:00
|
|
|
char *ref, *last_ref = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-11-20 21:46:37 +01:00
|
|
|
if (refs == NULL || *refs == '\0')
|
2013-03-06 04:31:49 +01:00
|
|
|
return NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
while (*refs) {
|
2009-11-16 05:21:43 +01:00
|
|
|
ref = _parse_message_id (ctx, refs, &refs);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2014-05-26 16:05:57 +02:00
|
|
|
if (ref && strcmp (ref, message_id)) {
|
2017-02-22 11:17:47 +01:00
|
|
|
g_hash_table_add (hash, ref);
|
2014-05-26 16:05:57 +02:00
|
|
|
last_ref = ref;
|
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
2013-03-06 04:31:49 +01:00
|
|
|
|
|
|
|
/* The return value of this function is used to add a parent
|
|
|
|
* reference to the database. We should avoid making a message
|
2014-05-26 16:05:57 +02:00
|
|
|
* its own parent, thus the above check.
|
2013-03-06 04:31:49 +01:00
|
|
|
*/
|
2017-02-22 11:17:47 +01:00
|
|
|
return talloc_strdup(ctx, last_ref);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2012-04-30 18:25:34 +02:00
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_create (const char *path, notmuch_database_t **database)
|
2014-12-27 19:12:49 +01:00
|
|
|
{
|
|
|
|
char *status_string = NULL;
|
|
|
|
notmuch_status_t status;
|
|
|
|
|
|
|
|
status = notmuch_database_create_verbose (path, database,
|
|
|
|
&status_string);
|
|
|
|
|
|
|
|
if (status_string) {
|
|
|
|
fputs (status_string, stderr);
|
|
|
|
free (status_string);
|
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_create_verbose (const char *path,
|
|
|
|
notmuch_database_t **database,
|
|
|
|
char **status_string)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2012-04-30 18:25:34 +02:00
|
|
|
notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
|
2009-10-20 18:56:25 +02:00
|
|
|
notmuch_database_t *notmuch = NULL;
|
|
|
|
char *notmuch_path = NULL;
|
2014-12-27 19:12:49 +01:00
|
|
|
char *message = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
struct stat st;
|
|
|
|
int err;
|
2009-10-20 18:56:25 +02:00
|
|
|
|
2009-11-12 02:01:55 +01:00
|
|
|
if (path == NULL) {
|
2014-12-27 19:12:49 +01:00
|
|
|
message = strdup ("Error: Cannot create a database for a NULL path.\n");
|
2012-04-30 18:25:34 +02:00
|
|
|
status = NOTMUCH_STATUS_NULL_POINTER;
|
2009-11-12 02:01:55 +01:00
|
|
|
goto DONE;
|
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2015-06-08 08:02:22 +02:00
|
|
|
if (path[0] != '/') {
|
|
|
|
message = strdup ("Error: Database path must be absolute.\n");
|
|
|
|
status = NOTMUCH_STATUS_PATH_ERROR;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
err = stat (path, &st);
|
|
|
|
if (err) {
|
2014-12-27 19:12:49 +01:00
|
|
|
IGNORE_RESULT (asprintf (&message, "Error: Cannot create database at %s: %s.\n",
|
|
|
|
path, strerror (errno)));
|
2012-04-30 18:25:34 +02:00
|
|
|
status = NOTMUCH_STATUS_FILE_ERROR;
|
2009-10-20 18:56:25 +02:00
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (! S_ISDIR (st.st_mode)) {
|
2014-12-27 19:12:49 +01:00
|
|
|
IGNORE_RESULT (asprintf (&message, "Error: Cannot create database at %s: "
|
|
|
|
"Not a directory.\n",
|
|
|
|
path));
|
2012-04-30 18:25:34 +02:00
|
|
|
status = NOTMUCH_STATUS_FILE_ERROR;
|
2009-10-20 18:56:25 +02:00
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
notmuch_path = talloc_asprintf (NULL, "%s/%s", path, ".notmuch");
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
err = mkdir (notmuch_path, 0755);
|
|
|
|
|
|
|
|
if (err) {
|
2014-12-27 19:12:49 +01:00
|
|
|
IGNORE_RESULT (asprintf (&message, "Error: Cannot create directory %s: %s.\n",
|
|
|
|
notmuch_path, strerror (errno)));
|
2012-04-30 18:25:34 +02:00
|
|
|
status = NOTMUCH_STATUS_FILE_ERROR;
|
2009-10-20 18:56:25 +02:00
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2014-12-27 19:12:49 +01:00
|
|
|
status = notmuch_database_open_verbose (path,
|
|
|
|
NOTMUCH_DATABASE_MODE_READ_WRITE,
|
|
|
|
¬much, &message);
|
2012-04-30 18:25:34 +02:00
|
|
|
if (status)
|
|
|
|
goto DONE;
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
|
2015-01-23 00:43:37 +01:00
|
|
|
/* Upgrade doesn't add these feature to existing databases, but
|
|
|
|
* new databases have them. */
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
notmuch->features |= NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES;
|
2015-01-23 00:43:37 +01:00
|
|
|
notmuch->features |= NOTMUCH_FEATURE_INDEXED_MIMETYPES;
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
|
2012-04-30 18:25:34 +02:00
|
|
|
status = notmuch_database_upgrade (notmuch, NULL, NULL);
|
|
|
|
if (status) {
|
|
|
|
notmuch_database_close(notmuch);
|
|
|
|
notmuch = NULL;
|
|
|
|
}
|
2009-10-20 18:56:25 +02:00
|
|
|
|
|
|
|
DONE:
|
|
|
|
if (notmuch_path)
|
2009-10-26 23:17:10 +01:00
|
|
|
talloc_free (notmuch_path);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2014-12-27 19:12:49 +01:00
|
|
|
if (message) {
|
|
|
|
if (status_string)
|
|
|
|
*status_string = message;
|
|
|
|
else
|
|
|
|
free (message);
|
|
|
|
}
|
2012-04-30 18:25:34 +02:00
|
|
|
if (database)
|
|
|
|
*database = notmuch;
|
|
|
|
else
|
|
|
|
talloc_free (notmuch);
|
|
|
|
return status;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2010-01-07 19:19:44 +01:00
|
|
|
notmuch_status_t
|
|
|
|
_notmuch_database_ensure_writable (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
if (notmuch->mode == NOTMUCH_DATABASE_MODE_READ_ONLY) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Cannot write to a read-only database.\n");
|
2010-01-07 19:29:05 +01:00
|
|
|
return NOTMUCH_STATUS_READ_ONLY_DATABASE;
|
2010-01-07 19:19:44 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
/* Allocate a revision number for the next change. */
|
|
|
|
unsigned long
|
|
|
|
_notmuch_database_new_revision (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
unsigned long new_revision = notmuch->revision + 1;
|
|
|
|
|
|
|
|
/* If we're in an atomic section, hold off on updating the
|
|
|
|
* committed revision number until we commit the atomic section.
|
|
|
|
*/
|
|
|
|
if (notmuch->atomic_nesting)
|
|
|
|
notmuch->atomic_dirty = TRUE;
|
|
|
|
else
|
|
|
|
notmuch->revision = new_revision;
|
|
|
|
|
|
|
|
return new_revision;
|
|
|
|
}
|
|
|
|
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
/* Parse a database features string from the given database version.
|
|
|
|
* Returns the feature bit set.
|
|
|
|
*
|
|
|
|
* For version < 3, this ignores the features string and returns a
|
|
|
|
* hard-coded set of features.
|
|
|
|
*
|
|
|
|
* If there are unrecognized features that are required to open the
|
|
|
|
* database in mode (which should be 'r' or 'w'), return a
|
|
|
|
* comma-separated list of unrecognized but required features in
|
|
|
|
* *incompat_out suitable for presenting to the user. *incompat_out
|
|
|
|
* will be allocated from ctx.
|
|
|
|
*/
|
|
|
|
static _notmuch_features
|
|
|
|
_parse_features (const void *ctx, const char *features, unsigned int version,
|
|
|
|
char mode, char **incompat_out)
|
|
|
|
{
|
|
|
|
_notmuch_features res = static_cast<_notmuch_features>(0);
|
|
|
|
unsigned int namelen, i;
|
|
|
|
size_t llen = 0;
|
|
|
|
const char *flags;
|
|
|
|
|
|
|
|
/* Prior to database version 3, features were implied by the
|
|
|
|
* version number. */
|
|
|
|
if (version == 0)
|
|
|
|
return NOTMUCH_FEATURES_V0;
|
|
|
|
else if (version == 1)
|
|
|
|
return NOTMUCH_FEATURES_V1;
|
|
|
|
else if (version == 2)
|
|
|
|
return NOTMUCH_FEATURES_V2;
|
|
|
|
|
|
|
|
/* Parse the features string */
|
|
|
|
while ((features = strtok_len_c (features + llen, "\n", &llen)) != NULL) {
|
|
|
|
flags = strchr (features, '\t');
|
|
|
|
if (! flags || flags > features + llen)
|
|
|
|
continue;
|
|
|
|
namelen = flags - features;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE (feature_names); ++i) {
|
|
|
|
if (strlen (feature_names[i].name) == namelen &&
|
|
|
|
strncmp (feature_names[i].name, features, namelen) == 0) {
|
|
|
|
res |= feature_names[i].value;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i == ARRAY_SIZE (feature_names) && incompat_out) {
|
|
|
|
/* Unrecognized feature */
|
|
|
|
const char *have = strchr (flags, mode);
|
|
|
|
if (have && have < features + llen) {
|
|
|
|
/* This feature is required to access this database in
|
|
|
|
* 'mode', but we don't understand it. */
|
|
|
|
if (! *incompat_out)
|
|
|
|
*incompat_out = talloc_strdup (ctx, "");
|
|
|
|
*incompat_out = talloc_asprintf_append_buffer (
|
|
|
|
*incompat_out, "%s%.*s", **incompat_out ? ", " : "",
|
|
|
|
namelen, features);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *
|
|
|
|
_print_features (const void *ctx, unsigned int features)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
char *res = talloc_strdup (ctx, "");
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE (feature_names); ++i)
|
|
|
|
if (features & feature_names[i].value)
|
|
|
|
res = talloc_asprintf_append_buffer (
|
|
|
|
res, "%s\t%s\n", feature_names[i].name, feature_names[i].flags);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2012-04-30 18:25:33 +02:00
|
|
|
notmuch_status_t
|
2009-11-21 20:54:25 +01:00
|
|
|
notmuch_database_open (const char *path,
|
2012-04-30 18:25:33 +02:00
|
|
|
notmuch_database_mode_t mode,
|
|
|
|
notmuch_database_t **database)
|
2014-12-27 19:12:49 +01:00
|
|
|
{
|
|
|
|
char *status_string = NULL;
|
|
|
|
notmuch_status_t status;
|
|
|
|
|
|
|
|
status = notmuch_database_open_verbose (path, mode, database,
|
|
|
|
&status_string);
|
|
|
|
|
|
|
|
if (status_string) {
|
|
|
|
fputs (status_string, stderr);
|
|
|
|
free (status_string);
|
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_open_verbose (const char *path,
|
|
|
|
notmuch_database_mode_t mode,
|
|
|
|
notmuch_database_t **database,
|
|
|
|
char **status_string)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2012-04-30 18:25:33 +02:00
|
|
|
notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
|
2012-01-29 06:50:10 +01:00
|
|
|
void *local = talloc_new (NULL);
|
2009-10-20 18:56:25 +02:00
|
|
|
notmuch_database_t *notmuch = NULL;
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
char *notmuch_path, *xapian_path, *incompat_features;
|
2014-12-27 19:12:49 +01:00
|
|
|
char *message = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
struct stat st;
|
|
|
|
int err;
|
2010-01-08 03:26:31 +01:00
|
|
|
unsigned int i, version;
|
2011-12-31 05:37:41 +01:00
|
|
|
static int initialized = 0;
|
2009-10-20 18:56:25 +02:00
|
|
|
|
2012-04-30 18:25:33 +02:00
|
|
|
if (path == NULL) {
|
2014-12-27 19:12:49 +01:00
|
|
|
message = strdup ("Error: Cannot open a database for a NULL path.\n");
|
2012-04-30 18:25:33 +02:00
|
|
|
status = NOTMUCH_STATUS_NULL_POINTER;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
2015-06-08 08:02:22 +02:00
|
|
|
if (path[0] != '/') {
|
|
|
|
message = strdup ("Error: Database path must be absolute.\n");
|
|
|
|
status = NOTMUCH_STATUS_PATH_ERROR;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
2012-01-29 06:50:10 +01:00
|
|
|
if (! (notmuch_path = talloc_asprintf (local, "%s/%s", path, ".notmuch"))) {
|
2014-12-27 19:12:49 +01:00
|
|
|
message = strdup ("Out of memory\n");
|
2012-04-30 18:25:33 +02:00
|
|
|
status = NOTMUCH_STATUS_OUT_OF_MEMORY;
|
2009-10-26 23:17:10 +01:00
|
|
|
goto DONE;
|
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
|
|
|
err = stat (notmuch_path, &st);
|
|
|
|
if (err) {
|
2014-12-27 19:12:49 +01:00
|
|
|
IGNORE_RESULT (asprintf (&message, "Error opening database at %s: %s\n",
|
|
|
|
notmuch_path, strerror (errno)));
|
2012-04-30 18:25:33 +02:00
|
|
|
status = NOTMUCH_STATUS_FILE_ERROR;
|
2009-10-20 18:56:25 +02:00
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2012-01-29 06:50:10 +01:00
|
|
|
if (! (xapian_path = talloc_asprintf (local, "%s/%s", notmuch_path, "xapian"))) {
|
2014-12-27 19:12:49 +01:00
|
|
|
message = strdup ("Out of memory\n");
|
2012-04-30 18:25:33 +02:00
|
|
|
status = NOTMUCH_STATUS_OUT_OF_MEMORY;
|
2009-10-26 23:17:10 +01:00
|
|
|
goto DONE;
|
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2011-12-04 20:20:39 +01:00
|
|
|
/* Initialize the GLib type system and threads */
|
2013-06-07 20:41:13 +02:00
|
|
|
#if !GLIB_CHECK_VERSION(2, 35, 1)
|
2011-12-04 20:20:39 +01:00
|
|
|
g_type_init ();
|
2013-06-07 20:41:13 +02:00
|
|
|
#endif
|
2011-12-04 20:20:39 +01:00
|
|
|
|
2011-12-31 05:37:41 +01:00
|
|
|
/* Initialize gmime */
|
|
|
|
if (! initialized) {
|
2013-09-11 19:36:43 +02:00
|
|
|
g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS);
|
2011-12-31 05:37:41 +01:00
|
|
|
initialized = 1;
|
|
|
|
}
|
|
|
|
|
2012-01-29 06:50:08 +01:00
|
|
|
notmuch = talloc_zero (NULL, notmuch_database_t);
|
2009-11-22 03:54:20 +01:00
|
|
|
notmuch->exception_reported = FALSE;
|
2014-12-26 09:01:01 +01:00
|
|
|
notmuch->status_string = NULL;
|
2009-10-21 23:00:37 +02:00
|
|
|
notmuch->path = talloc_strdup (notmuch, path);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-29 00:50:14 +01:00
|
|
|
if (notmuch->path[strlen (notmuch->path) - 1] == '/')
|
|
|
|
notmuch->path[strlen (notmuch->path) - 1] = '\0';
|
|
|
|
|
2009-11-21 20:54:25 +01:00
|
|
|
notmuch->mode = mode;
|
2011-06-11 05:35:06 +02:00
|
|
|
notmuch->atomic_nesting = 0;
|
2017-02-24 02:38:24 +01:00
|
|
|
notmuch->view = 1;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
try {
|
2010-02-08 20:33:33 +01:00
|
|
|
string last_thread_id;
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
string last_mod;
|
2010-02-08 20:33:33 +01:00
|
|
|
|
2009-11-21 22:10:18 +01:00
|
|
|
if (mode == NOTMUCH_DATABASE_MODE_READ_WRITE) {
|
2009-11-21 20:54:25 +01:00
|
|
|
notmuch->xapian_db = new Xapian::WritableDatabase (xapian_path,
|
2016-06-26 17:29:43 +02:00
|
|
|
DB_ACTION);
|
2009-11-21 20:54:25 +01:00
|
|
|
} else {
|
|
|
|
notmuch->xapian_db = new Xapian::Database (xapian_path);
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Check version. As of database version 3, we represent
|
|
|
|
* changes in terms of features, so assume a version bump
|
|
|
|
* means a dramatically incompatible change. */
|
|
|
|
version = notmuch_database_get_version (notmuch);
|
|
|
|
if (version > NOTMUCH_DATABASE_VERSION) {
|
2014-12-27 19:12:49 +01:00
|
|
|
IGNORE_RESULT (asprintf (&message,
|
|
|
|
"Error: Notmuch database at %s\n"
|
|
|
|
" has a newer database format version (%u) than supported by this\n"
|
|
|
|
" version of notmuch (%u).\n",
|
|
|
|
notmuch_path, version, NOTMUCH_DATABASE_VERSION));
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
|
|
|
|
notmuch_database_destroy (notmuch);
|
|
|
|
notmuch = NULL;
|
|
|
|
status = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check features. */
|
|
|
|
incompat_features = NULL;
|
|
|
|
notmuch->features = _parse_features (
|
|
|
|
local, notmuch->xapian_db->get_metadata ("features").c_str (),
|
|
|
|
version, mode == NOTMUCH_DATABASE_MODE_READ_WRITE ? 'w' : 'r',
|
|
|
|
&incompat_features);
|
|
|
|
if (incompat_features) {
|
2014-12-27 19:12:49 +01:00
|
|
|
IGNORE_RESULT (asprintf (&message,
|
|
|
|
"Error: Notmuch database at %s\n"
|
|
|
|
" requires features (%s)\n"
|
|
|
|
" not supported by this version of notmuch.\n",
|
|
|
|
notmuch_path, incompat_features));
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
|
|
|
|
notmuch_database_destroy (notmuch);
|
|
|
|
notmuch = NULL;
|
|
|
|
status = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
2009-11-21 20:54:25 +01:00
|
|
|
}
|
2010-02-08 20:33:33 +01:00
|
|
|
|
2010-06-04 19:16:53 +02:00
|
|
|
notmuch->last_doc_id = notmuch->xapian_db->get_lastdocid ();
|
2010-02-08 20:33:33 +01:00
|
|
|
last_thread_id = notmuch->xapian_db->get_metadata ("last_thread_id");
|
|
|
|
if (last_thread_id.empty ()) {
|
|
|
|
notmuch->last_thread_id = 0;
|
|
|
|
} else {
|
|
|
|
const char *str;
|
|
|
|
char *end;
|
|
|
|
|
|
|
|
str = last_thread_id.c_str ();
|
|
|
|
notmuch->last_thread_id = strtoull (str, &end, 16);
|
|
|
|
if (*end != '\0')
|
|
|
|
INTERNAL_ERROR ("Malformed database last_thread_id: %s", str);
|
|
|
|
}
|
|
|
|
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
/* Get current highest revision number. */
|
|
|
|
last_mod = notmuch->xapian_db->get_value_upper_bound (
|
|
|
|
NOTMUCH_VALUE_LAST_MOD);
|
|
|
|
if (last_mod.empty ())
|
|
|
|
notmuch->revision = 0;
|
|
|
|
else
|
|
|
|
notmuch->revision = Xapian::sortable_unserialise (last_mod);
|
2014-10-13 08:20:02 +02:00
|
|
|
notmuch->uuid = talloc_strdup (
|
|
|
|
notmuch, notmuch->xapian_db->get_uuid ().c_str ());
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
|
2009-10-21 09:35:56 +02:00
|
|
|
notmuch->query_parser = new Xapian::QueryParser;
|
2009-10-28 18:42:07 +01:00
|
|
|
notmuch->term_gen = new Xapian::TermGenerator;
|
|
|
|
notmuch->term_gen->set_stemmer (Xapian::Stem ("english"));
|
2009-11-23 16:58:35 +01:00
|
|
|
notmuch->value_range_processor = new Xapian::NumberValueRangeProcessor (NOTMUCH_VALUE_TIMESTAMP);
|
lib: add date range query support
Add a custom value range processor to enable date and time searches of
the form date:since..until, where "since" and "until" are expressions
understood by the previously added date/time parser, to restrict the
results to messages within a particular time range (based on the Date:
header).
If "since" or "until" describes date/time at an accuracy of days or
less, the values are rounded according to the accuracy, towards past
for "since" and towards future for "until". For example,
date:november..yesterday would match from the beginning of November
until the end of yesterday. Expressions such as date:today..today
means since the beginning of today until the end of today.
Open-ended ranges are supported (since Xapian 1.2.1), i.e. you can
specify date:..until or date:since.. to not limit the start or end
date, respectively.
CAVEATS:
Xapian does not support spaces in range expressions. You can replace
the spaces with '_', or (in most cases) '-', or (in some cases) leave
the spaces out altogether.
Entering date:expr without ".." (for example date:yesterday) will not
work as you might expect. You can achieve the expected result by
duplicating the expr both sides of ".." (for example
date:yesterday..yesterday).
Open-ended ranges won't work with pre-1.2.1 Xapian, but they don't
produce an error either.
Signed-off-by: Jani Nikula <jani@nikula.org>
2012-10-30 21:32:37 +01:00
|
|
|
notmuch->date_range_processor = new ParseTimeValueRangeProcessor (NOTMUCH_VALUE_TIMESTAMP);
|
2016-03-22 11:54:44 +01:00
|
|
|
#if HAVE_XAPIAN_FIELD_PROCESSOR
|
|
|
|
/* This currently relies on the query parser to pass anything
|
|
|
|
* with a .. to the range processor */
|
2017-02-17 04:07:50 +01:00
|
|
|
{
|
|
|
|
Xapian::FieldProcessor * date_fp = new DateFieldProcessor();
|
|
|
|
Xapian::FieldProcessor * query_fp =
|
|
|
|
new QueryFieldProcessor (*notmuch->query_parser, notmuch);
|
|
|
|
|
|
|
|
notmuch->query_parser->add_boolean_prefix("date", date_fp->release ());
|
|
|
|
notmuch->query_parser->add_boolean_prefix("query", query_fp->release ());
|
|
|
|
}
|
2016-03-22 11:54:44 +01:00
|
|
|
#endif
|
2014-10-13 08:20:03 +02:00
|
|
|
notmuch->last_mod_range_processor = new Xapian::NumberValueRangeProcessor (NOTMUCH_VALUE_LAST_MOD, "lastmod:");
|
2009-10-28 18:42:07 +01:00
|
|
|
|
2009-10-21 09:35:56 +02:00
|
|
|
notmuch->query_parser->set_default_op (Xapian::Query::OP_AND);
|
|
|
|
notmuch->query_parser->set_database (*notmuch->xapian_db);
|
2009-10-28 18:42:07 +01:00
|
|
|
notmuch->query_parser->set_stemmer (Xapian::Stem ("english"));
|
|
|
|
notmuch->query_parser->set_stemming_strategy (Xapian::QueryParser::STEM_SOME);
|
2009-11-23 16:58:35 +01:00
|
|
|
notmuch->query_parser->add_valuerangeprocessor (notmuch->value_range_processor);
|
lib: add date range query support
Add a custom value range processor to enable date and time searches of
the form date:since..until, where "since" and "until" are expressions
understood by the previously added date/time parser, to restrict the
results to messages within a particular time range (based on the Date:
header).
If "since" or "until" describes date/time at an accuracy of days or
less, the values are rounded according to the accuracy, towards past
for "since" and towards future for "until". For example,
date:november..yesterday would match from the beginning of November
until the end of yesterday. Expressions such as date:today..today
means since the beginning of today until the end of today.
Open-ended ranges are supported (since Xapian 1.2.1), i.e. you can
specify date:..until or date:since.. to not limit the start or end
date, respectively.
CAVEATS:
Xapian does not support spaces in range expressions. You can replace
the spaces with '_', or (in most cases) '-', or (in some cases) leave
the spaces out altogether.
Entering date:expr without ".." (for example date:yesterday) will not
work as you might expect. You can achieve the expected result by
duplicating the expr both sides of ".." (for example
date:yesterday..yesterday).
Open-ended ranges won't work with pre-1.2.1 Xapian, but they don't
produce an error either.
Signed-off-by: Jani Nikula <jani@nikula.org>
2012-10-30 21:32:37 +01:00
|
|
|
notmuch->query_parser->add_valuerangeprocessor (notmuch->date_range_processor);
|
2014-10-13 08:20:03 +02:00
|
|
|
notmuch->query_parser->add_valuerangeprocessor (notmuch->last_mod_range_processor);
|
2009-10-25 06:38:43 +01:00
|
|
|
|
2017-02-17 04:07:49 +01:00
|
|
|
for (i = 0; i < ARRAY_SIZE (prefix_table); i++) {
|
|
|
|
const prefix_t *prefix = &prefix_table[i];
|
|
|
|
if (prefix->flags & NOTMUCH_FIELD_EXTERNAL) {
|
|
|
|
if (prefix->flags & NOTMUCH_FIELD_PROBABILISTIC) {
|
|
|
|
notmuch->query_parser->add_prefix (prefix->name, prefix->prefix);
|
|
|
|
} else {
|
|
|
|
notmuch->query_parser->add_boolean_prefix (prefix->name,
|
|
|
|
prefix->prefix);
|
|
|
|
}
|
|
|
|
}
|
2009-10-28 18:42:07 +01:00
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-27 19:12:49 +01:00
|
|
|
IGNORE_RESULT (asprintf (&message, "A Xapian exception occurred opening database: %s\n",
|
|
|
|
error.get_msg().c_str()));
|
2012-04-25 15:20:16 +02:00
|
|
|
notmuch_database_destroy (notmuch);
|
2009-10-28 07:57:37 +01:00
|
|
|
notmuch = NULL;
|
2012-04-30 18:25:33 +02:00
|
|
|
status = NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
2009-11-22 00:14:39 +01:00
|
|
|
|
2009-10-20 18:56:25 +02:00
|
|
|
DONE:
|
2012-01-29 06:50:10 +01:00
|
|
|
talloc_free (local);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2014-12-27 19:12:49 +01:00
|
|
|
if (message) {
|
|
|
|
if (status_string)
|
|
|
|
*status_string = message;
|
|
|
|
else
|
|
|
|
free (message);
|
|
|
|
}
|
|
|
|
|
2012-04-30 18:25:33 +02:00
|
|
|
if (database)
|
|
|
|
*database = notmuch;
|
|
|
|
else
|
|
|
|
talloc_free (notmuch);
|
|
|
|
return status;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2014-04-16 14:59:16 +02:00
|
|
|
notmuch_status_t
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
notmuch_database_close (notmuch_database_t *notmuch)
|
|
|
|
{
|
2014-04-16 14:59:16 +02:00
|
|
|
notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
|
|
|
|
|
2012-03-02 15:58:39 +01:00
|
|
|
/* Many Xapian objects (and thus notmuch objects) hold references to
|
|
|
|
* the database, so merely deleting the database may not suffice to
|
|
|
|
* close it. Thus, we explicitly close it here. */
|
|
|
|
if (notmuch->xapian_db != NULL) {
|
|
|
|
try {
|
lib: Simplify close and codify aborting atomic section
In Xapian, closing a database implicitly aborts any outstanding
transaction and commits changes. For historical reasons,
notmuch_database_close had grown to almost, but not quite duplicate
this behavior. Before closing the database, it would explicitly (and
unnecessarily) commit it. However, if there was an outstanding
transaction (ie atomic section), commit would throw a Xapian
exception, which notmuch_database_close would unnecessarily print to
stderr, even though notmuch_database_close would ultimately abort the
transaction anyway when it called close.
This patch simplifies notmuch_database_close to explicitly abort any
outstanding transaction and then just call Database::close. This
works for both read-only and read/write databases, takes care of
committing changes, unifies the exception handling path, and codifies
aborting outstanding transactions. This is currently the only way to
abort an atomic section (and may remain so, since it would be
difficult to roll back things we may have cached from rolled-back
modifications).
2014-10-02 21:19:08 +02:00
|
|
|
/* If there's an outstanding transaction, it's unclear if
|
|
|
|
* closing the Xapian database commits everything up to
|
|
|
|
* that transaction, or may discard committed (but
|
|
|
|
* unflushed) transactions. To be certain, explicitly
|
|
|
|
* cancel any outstanding transaction before closing. */
|
|
|
|
if (notmuch->mode == NOTMUCH_DATABASE_MODE_READ_WRITE &&
|
|
|
|
notmuch->atomic_nesting)
|
|
|
|
(static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db))
|
|
|
|
->cancel_transaction ();
|
|
|
|
|
|
|
|
/* Close the database. This implicitly flushes
|
|
|
|
* outstanding changes. */
|
2012-03-02 15:58:39 +01:00
|
|
|
notmuch->xapian_db->close();
|
|
|
|
} catch (const Xapian::Error &error) {
|
lib: Simplify close and codify aborting atomic section
In Xapian, closing a database implicitly aborts any outstanding
transaction and commits changes. For historical reasons,
notmuch_database_close had grown to almost, but not quite duplicate
this behavior. Before closing the database, it would explicitly (and
unnecessarily) commit it. However, if there was an outstanding
transaction (ie atomic section), commit would throw a Xapian
exception, which notmuch_database_close would unnecessarily print to
stderr, even though notmuch_database_close would ultimately abort the
transaction anyway when it called close.
This patch simplifies notmuch_database_close to explicitly abort any
outstanding transaction and then just call Database::close. This
works for both read-only and read/write databases, takes care of
committing changes, unifies the exception handling path, and codifies
aborting outstanding transactions. This is currently the only way to
abort an atomic section (and may remain so, since it would be
difficult to roll back things we may have cached from rolled-back
modifications).
2014-10-02 21:19:08 +02:00
|
|
|
status = NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
if (! notmuch->exception_reported) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Error: A Xapian exception occurred closing database: %s\n",
|
lib: Simplify close and codify aborting atomic section
In Xapian, closing a database implicitly aborts any outstanding
transaction and commits changes. For historical reasons,
notmuch_database_close had grown to almost, but not quite duplicate
this behavior. Before closing the database, it would explicitly (and
unnecessarily) commit it. However, if there was an outstanding
transaction (ie atomic section), commit would throw a Xapian
exception, which notmuch_database_close would unnecessarily print to
stderr, even though notmuch_database_close would ultimately abort the
transaction anyway when it called close.
This patch simplifies notmuch_database_close to explicitly abort any
outstanding transaction and then just call Database::close. This
works for both read-only and read/write databases, takes care of
committing changes, unifies the exception handling path, and codifies
aborting outstanding transactions. This is currently the only way to
abort an atomic section (and may remain so, since it would be
difficult to roll back things we may have cached from rolled-back
modifications).
2014-10-02 21:19:08 +02:00
|
|
|
error.get_msg().c_str());
|
|
|
|
}
|
2012-03-02 15:58:39 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-10-28 18:42:07 +01:00
|
|
|
delete notmuch->term_gen;
|
2012-04-25 15:20:16 +02:00
|
|
|
notmuch->term_gen = NULL;
|
2009-10-21 09:35:56 +02:00
|
|
|
delete notmuch->query_parser;
|
2012-04-25 15:20:16 +02:00
|
|
|
notmuch->query_parser = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
delete notmuch->xapian_db;
|
2012-04-25 15:20:16 +02:00
|
|
|
notmuch->xapian_db = NULL;
|
2009-11-23 16:58:35 +01:00
|
|
|
delete notmuch->value_range_processor;
|
2012-04-25 15:20:16 +02:00
|
|
|
notmuch->value_range_processor = NULL;
|
lib: add date range query support
Add a custom value range processor to enable date and time searches of
the form date:since..until, where "since" and "until" are expressions
understood by the previously added date/time parser, to restrict the
results to messages within a particular time range (based on the Date:
header).
If "since" or "until" describes date/time at an accuracy of days or
less, the values are rounded according to the accuracy, towards past
for "since" and towards future for "until". For example,
date:november..yesterday would match from the beginning of November
until the end of yesterday. Expressions such as date:today..today
means since the beginning of today until the end of today.
Open-ended ranges are supported (since Xapian 1.2.1), i.e. you can
specify date:..until or date:since.. to not limit the start or end
date, respectively.
CAVEATS:
Xapian does not support spaces in range expressions. You can replace
the spaces with '_', or (in most cases) '-', or (in some cases) leave
the spaces out altogether.
Entering date:expr without ".." (for example date:yesterday) will not
work as you might expect. You can achieve the expected result by
duplicating the expr both sides of ".." (for example
date:yesterday..yesterday).
Open-ended ranges won't work with pre-1.2.1 Xapian, but they don't
produce an error either.
Signed-off-by: Jani Nikula <jani@nikula.org>
2012-10-30 21:32:37 +01:00
|
|
|
delete notmuch->date_range_processor;
|
|
|
|
notmuch->date_range_processor = NULL;
|
2014-10-13 08:20:03 +02:00
|
|
|
delete notmuch->last_mod_range_processor;
|
|
|
|
notmuch->last_mod_range_processor = NULL;
|
2014-04-16 14:59:16 +02:00
|
|
|
|
|
|
|
return status;
|
2012-04-25 15:20:16 +02:00
|
|
|
}
|
|
|
|
|
2017-02-24 02:38:24 +01:00
|
|
|
notmuch_status_t
|
|
|
|
_notmuch_database_reopen (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
if (notmuch->mode != NOTMUCH_DATABASE_MODE_READ_ONLY)
|
|
|
|
return NOTMUCH_STATUS_UNSUPPORTED_OPERATION;
|
|
|
|
|
|
|
|
try {
|
|
|
|
notmuch->xapian_db->reopen ();
|
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
if (! notmuch->exception_reported) {
|
|
|
|
_notmuch_database_log (notmuch, "Error: A Xapian exception reopening database: %s\n",
|
|
|
|
error.get_msg ().c_str ());
|
|
|
|
notmuch->exception_reported = TRUE;
|
|
|
|
}
|
|
|
|
return NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch->view++;
|
|
|
|
|
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2013-11-13 18:02:43 +01:00
|
|
|
static int
|
|
|
|
unlink_cb (const char *path,
|
|
|
|
unused (const struct stat *sb),
|
|
|
|
unused (int type),
|
|
|
|
unused (struct FTW *ftw))
|
2013-10-02 22:30:46 +02:00
|
|
|
{
|
2013-11-13 18:02:43 +01:00
|
|
|
return remove (path);
|
2013-10-02 22:30:46 +02:00
|
|
|
}
|
|
|
|
|
2013-11-13 18:02:43 +01:00
|
|
|
static int
|
|
|
|
rmtree (const char *path)
|
2013-10-02 22:30:46 +02:00
|
|
|
{
|
2013-11-13 18:02:43 +01:00
|
|
|
return nftw (path, unlink_cb, 64, FTW_DEPTH | FTW_PHYS);
|
2013-10-02 22:30:46 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
class NotmuchCompactor : public Xapian::Compactor
|
|
|
|
{
|
|
|
|
notmuch_compact_status_cb_t status_cb;
|
2013-11-03 13:24:45 +01:00
|
|
|
void *status_closure;
|
2013-10-02 22:30:46 +02:00
|
|
|
|
|
|
|
public:
|
2013-11-03 13:24:45 +01:00
|
|
|
NotmuchCompactor(notmuch_compact_status_cb_t cb, void *closure) :
|
2013-11-13 18:02:43 +01:00
|
|
|
status_cb (cb), status_closure (closure) { }
|
2013-10-02 22:30:46 +02:00
|
|
|
|
|
|
|
virtual void
|
|
|
|
set_status (const std::string &table, const std::string &status)
|
|
|
|
{
|
2013-11-13 18:02:43 +01:00
|
|
|
char *msg;
|
2013-10-02 22:30:46 +02:00
|
|
|
|
|
|
|
if (status_cb == NULL)
|
|
|
|
return;
|
|
|
|
|
2013-11-13 18:02:43 +01:00
|
|
|
if (status.length () == 0)
|
2013-10-02 22:30:46 +02:00
|
|
|
msg = talloc_asprintf (NULL, "compacting table %s", table.c_str());
|
|
|
|
else
|
|
|
|
msg = talloc_asprintf (NULL, " %s", status.c_str());
|
|
|
|
|
|
|
|
if (msg == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-11-13 18:02:43 +01:00
|
|
|
status_cb (msg, status_closure);
|
|
|
|
talloc_free (msg);
|
2013-10-02 22:30:46 +02:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Compacts the given database, optionally saving the original database
|
|
|
|
* in backup_path. Additionally, a callback function can be provided to
|
|
|
|
* give the user feedback on the progress of the (likely long-lived)
|
|
|
|
* compaction process.
|
|
|
|
*
|
|
|
|
* The backup path must point to a directory on the same volume as the
|
|
|
|
* original database. Passing a NULL backup_path will result in the
|
|
|
|
* uncompacted database being deleted after compaction has finished.
|
|
|
|
* Note that the database write lock will be held during the
|
|
|
|
* compaction process to protect data integrity.
|
|
|
|
*/
|
|
|
|
notmuch_status_t
|
2013-11-13 18:02:43 +01:00
|
|
|
notmuch_database_compact (const char *path,
|
|
|
|
const char *backup_path,
|
2013-11-03 13:24:45 +01:00
|
|
|
notmuch_compact_status_cb_t status_cb,
|
|
|
|
void *closure)
|
2013-10-02 22:30:46 +02:00
|
|
|
{
|
2013-11-03 13:24:43 +01:00
|
|
|
void *local;
|
2013-10-02 22:30:46 +02:00
|
|
|
char *notmuch_path, *xapian_path, *compact_xapian_path;
|
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
|
|
|
|
notmuch_database_t *notmuch = NULL;
|
|
|
|
struct stat statbuf;
|
2013-11-14 23:03:25 +01:00
|
|
|
notmuch_bool_t keep_backup;
|
2014-12-27 19:12:49 +01:00
|
|
|
char *message = NULL;
|
2013-10-02 22:30:46 +02:00
|
|
|
|
2013-11-03 13:24:43 +01:00
|
|
|
local = talloc_new (NULL);
|
|
|
|
if (! local)
|
|
|
|
return NOTMUCH_STATUS_OUT_OF_MEMORY;
|
|
|
|
|
2014-12-27 19:12:49 +01:00
|
|
|
ret = notmuch_database_open_verbose (path,
|
|
|
|
NOTMUCH_DATABASE_MODE_READ_WRITE,
|
|
|
|
¬much,
|
|
|
|
&message);
|
2013-10-02 22:30:46 +02:00
|
|
|
if (ret) {
|
2014-12-27 19:12:49 +01:00
|
|
|
if (status_cb) status_cb (message, closure);
|
2013-10-02 22:30:46 +02:00
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (! (notmuch_path = talloc_asprintf (local, "%s/%s", path, ".notmuch"))) {
|
|
|
|
ret = NOTMUCH_STATUS_OUT_OF_MEMORY;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (! (xapian_path = talloc_asprintf (local, "%s/%s", notmuch_path, "xapian"))) {
|
|
|
|
ret = NOTMUCH_STATUS_OUT_OF_MEMORY;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (! (compact_xapian_path = talloc_asprintf (local, "%s.compact", xapian_path))) {
|
|
|
|
ret = NOTMUCH_STATUS_OUT_OF_MEMORY;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
2013-11-14 23:03:25 +01:00
|
|
|
if (backup_path == NULL) {
|
|
|
|
if (! (backup_path = talloc_asprintf (local, "%s.old", xapian_path))) {
|
|
|
|
ret = NOTMUCH_STATUS_OUT_OF_MEMORY;
|
2013-10-02 22:30:46 +02:00
|
|
|
goto DONE;
|
|
|
|
}
|
2013-11-14 23:03:25 +01:00
|
|
|
keep_backup = FALSE;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
keep_backup = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stat (backup_path, &statbuf) != -1) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Path already exists: %s\n", backup_path);
|
2013-11-14 23:03:25 +01:00
|
|
|
ret = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
if (errno != ENOENT) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Unknown error while stat()ing path: %s\n",
|
2013-11-14 23:03:25 +01:00
|
|
|
strerror (errno));
|
|
|
|
ret = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
2013-10-02 22:30:46 +02:00
|
|
|
}
|
|
|
|
|
2013-11-14 23:03:26 +01:00
|
|
|
/* Unconditionally attempt to remove old work-in-progress database (if
|
|
|
|
* any). This is "protected" by database lock. If this fails due to write
|
|
|
|
* errors (etc), the following code will fail and provide error message.
|
|
|
|
*/
|
|
|
|
(void) rmtree (compact_xapian_path);
|
|
|
|
|
2013-10-02 22:30:46 +02:00
|
|
|
try {
|
2013-11-13 18:02:43 +01:00
|
|
|
NotmuchCompactor compactor (status_cb, closure);
|
2013-11-03 13:24:42 +01:00
|
|
|
|
2013-11-13 18:02:43 +01:00
|
|
|
compactor.set_renumber (false);
|
|
|
|
compactor.add_source (xapian_path);
|
|
|
|
compactor.set_destdir (compact_xapian_path);
|
|
|
|
compactor.compact ();
|
2013-11-13 18:02:44 +01:00
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Error while compacting: %s\n", error.get_msg().c_str());
|
2013-10-02 22:30:46 +02:00
|
|
|
ret = NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
2013-11-14 23:03:25 +01:00
|
|
|
if (rename (xapian_path, backup_path)) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Error moving %s to %s: %s\n",
|
2013-11-14 23:03:27 +01:00
|
|
|
xapian_path, backup_path, strerror (errno));
|
2013-11-14 23:03:25 +01:00
|
|
|
ret = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
2013-10-02 22:30:46 +02:00
|
|
|
}
|
|
|
|
|
2013-11-13 18:02:43 +01:00
|
|
|
if (rename (compact_xapian_path, xapian_path)) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Error moving %s to %s: %s\n",
|
2013-11-14 23:03:27 +01:00
|
|
|
compact_xapian_path, xapian_path, strerror (errno));
|
2013-10-02 22:30:46 +02:00
|
|
|
ret = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
2013-11-14 23:03:27 +01:00
|
|
|
if (! keep_backup) {
|
|
|
|
if (rmtree (backup_path)) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Error removing old database %s: %s\n",
|
2013-11-14 23:03:27 +01:00
|
|
|
backup_path, strerror (errno));
|
|
|
|
ret = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
}
|
2013-11-14 23:03:25 +01:00
|
|
|
|
2013-11-13 18:02:43 +01:00
|
|
|
DONE:
|
2014-04-16 14:59:16 +02:00
|
|
|
if (notmuch) {
|
|
|
|
notmuch_status_t ret2;
|
|
|
|
|
2014-12-26 17:25:35 +01:00
|
|
|
const char *str = notmuch_database_status_string (notmuch);
|
|
|
|
if (status_cb && str)
|
|
|
|
status_cb (str, closure);
|
|
|
|
|
2014-04-16 14:59:16 +02:00
|
|
|
ret2 = notmuch_database_destroy (notmuch);
|
|
|
|
|
|
|
|
/* don't clobber previous error status */
|
|
|
|
if (ret == NOTMUCH_STATUS_SUCCESS && ret2 != NOTMUCH_STATUS_SUCCESS)
|
|
|
|
ret = ret2;
|
|
|
|
}
|
2013-11-03 13:24:44 +01:00
|
|
|
|
2013-11-13 18:02:43 +01:00
|
|
|
talloc_free (local);
|
2013-11-03 13:24:44 +01:00
|
|
|
|
2013-10-02 22:30:46 +02:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-04-16 14:59:16 +02:00
|
|
|
notmuch_status_t
|
2012-04-25 15:20:16 +02:00
|
|
|
notmuch_database_destroy (notmuch_database_t *notmuch)
|
|
|
|
{
|
2014-04-16 14:59:16 +02:00
|
|
|
notmuch_status_t status;
|
|
|
|
|
|
|
|
status = notmuch_database_close (notmuch);
|
2009-10-21 23:00:37 +02:00
|
|
|
talloc_free (notmuch);
|
2014-04-16 14:59:16 +02:00
|
|
|
|
|
|
|
return status;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
const char *
|
|
|
|
notmuch_database_get_path (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
return notmuch->path;
|
|
|
|
}
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
unsigned int
|
|
|
|
notmuch_database_get_version (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
unsigned int version;
|
|
|
|
string version_string;
|
|
|
|
const char *str;
|
|
|
|
char *end;
|
|
|
|
|
|
|
|
version_string = notmuch->xapian_db->get_metadata ("version");
|
|
|
|
if (version_string.empty ())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
str = version_string.c_str ();
|
|
|
|
if (str == NULL || *str == '\0')
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
version = strtoul (str, &end, 10);
|
|
|
|
if (*end != '\0')
|
|
|
|
INTERNAL_ERROR ("Malformed database version: %s", str);
|
|
|
|
|
|
|
|
return version;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_bool_t
|
|
|
|
notmuch_database_needs_upgrade (notmuch_database_t *notmuch)
|
|
|
|
{
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
return notmuch->mode == NOTMUCH_DATABASE_MODE_READ_WRITE &&
|
|
|
|
((NOTMUCH_FEATURES_CURRENT & ~notmuch->features) ||
|
|
|
|
(notmuch_database_get_version (notmuch) < NOTMUCH_DATABASE_VERSION));
|
2010-01-08 03:26:31 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static volatile sig_atomic_t do_progress_notify = 0;
|
|
|
|
|
|
|
|
static void
|
|
|
|
handle_sigalrm (unused (int signal))
|
|
|
|
{
|
|
|
|
do_progress_notify = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Upgrade the current database.
|
|
|
|
*
|
|
|
|
* After opening a database in read-write mode, the client should
|
|
|
|
* check if an upgrade is needed (notmuch_database_needs_upgrade) and
|
|
|
|
* if so, upgrade with this function before making any modifications.
|
|
|
|
*
|
|
|
|
* The optional progress_notify callback can be used by the caller to
|
|
|
|
* provide progress indication to the user. If non-NULL it will be
|
|
|
|
* called periodically with 'count' as the number of messages upgraded
|
|
|
|
* so far and 'total' the overall number of messages that will be
|
|
|
|
* converted.
|
|
|
|
*/
|
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_upgrade (notmuch_database_t *notmuch,
|
|
|
|
void (*progress_notify) (void *closure,
|
2010-01-10 02:38:23 +01:00
|
|
|
double progress),
|
2010-01-08 03:26:31 +01:00
|
|
|
void *closure)
|
|
|
|
{
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
void *local = talloc_new (NULL);
|
2014-08-25 19:26:04 +02:00
|
|
|
Xapian::TermIterator t, t_end;
|
2010-01-08 03:26:31 +01:00
|
|
|
Xapian::WritableDatabase *db;
|
|
|
|
struct sigaction action;
|
|
|
|
struct itimerval timerval;
|
|
|
|
notmuch_bool_t timer_is_active = FALSE;
|
2014-08-25 19:26:04 +02:00
|
|
|
enum _notmuch_features target_features, new_features;
|
2010-01-08 03:26:31 +01:00
|
|
|
notmuch_status_t status;
|
2014-10-23 14:30:38 +02:00
|
|
|
notmuch_private_status_t private_status;
|
2015-09-27 17:31:55 +02:00
|
|
|
notmuch_query_t *query = NULL;
|
2010-01-10 02:38:23 +01:00
|
|
|
unsigned int count = 0, total = 0;
|
2010-01-08 03:26:31 +01:00
|
|
|
|
|
|
|
status = _notmuch_database_ensure_writable (notmuch);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
|
2014-08-25 19:26:04 +02:00
|
|
|
target_features = notmuch->features | NOTMUCH_FEATURES_CURRENT;
|
|
|
|
new_features = NOTMUCH_FEATURES_CURRENT & ~notmuch->features;
|
2010-01-08 03:26:31 +01:00
|
|
|
|
2014-09-02 00:49:07 +02:00
|
|
|
if (! notmuch_database_needs_upgrade (notmuch))
|
2010-01-08 03:26:31 +01:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
|
|
|
|
if (progress_notify) {
|
2015-05-27 19:53:52 +02:00
|
|
|
/* Set up our handler for SIGALRM */
|
2010-01-08 03:26:31 +01:00
|
|
|
memset (&action, 0, sizeof (struct sigaction));
|
|
|
|
action.sa_handler = handle_sigalrm;
|
|
|
|
sigemptyset (&action.sa_mask);
|
|
|
|
action.sa_flags = SA_RESTART;
|
|
|
|
sigaction (SIGALRM, &action, NULL);
|
|
|
|
|
|
|
|
/* Then start a timer to send SIGALRM once per second. */
|
|
|
|
timerval.it_interval.tv_sec = 1;
|
|
|
|
timerval.it_interval.tv_usec = 0;
|
|
|
|
timerval.it_value.tv_sec = 1;
|
|
|
|
timerval.it_value.tv_usec = 0;
|
|
|
|
setitimer (ITIMER_REAL, &timerval, NULL);
|
|
|
|
|
|
|
|
timer_is_active = TRUE;
|
|
|
|
}
|
|
|
|
|
2014-08-25 19:26:06 +02:00
|
|
|
/* Figure out how much total work we need to do. */
|
|
|
|
if (new_features &
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
(NOTMUCH_FEATURE_FILE_TERMS | NOTMUCH_FEATURE_BOOL_FOLDER |
|
|
|
|
NOTMUCH_FEATURE_LAST_MOD)) {
|
2015-09-27 17:31:55 +02:00
|
|
|
query = notmuch_query_create (notmuch, "");
|
2015-09-27 17:31:57 +02:00
|
|
|
unsigned msg_count;
|
|
|
|
|
|
|
|
status = notmuch_query_count_messages_st (query, &msg_count);
|
|
|
|
if (status)
|
|
|
|
goto DONE;
|
|
|
|
|
|
|
|
total += msg_count;
|
2014-08-25 19:26:06 +02:00
|
|
|
notmuch_query_destroy (query);
|
2015-09-27 17:31:57 +02:00
|
|
|
query = NULL;
|
2014-08-25 19:26:06 +02:00
|
|
|
}
|
|
|
|
if (new_features & NOTMUCH_FEATURE_DIRECTORY_DOCS) {
|
|
|
|
t_end = db->allterms_end ("XTIMESTAMP");
|
|
|
|
for (t = db->allterms_begin ("XTIMESTAMP"); t != t_end; t++)
|
|
|
|
++total;
|
|
|
|
}
|
2014-10-23 14:30:38 +02:00
|
|
|
if (new_features & NOTMUCH_FEATURE_GHOSTS) {
|
|
|
|
/* The ghost message upgrade converts all thread_id_*
|
|
|
|
* metadata values into ghost message documents. */
|
|
|
|
t_end = db->metadata_keys_end ("thread_id_");
|
|
|
|
for (t = db->metadata_keys_begin ("thread_id_"); t != t_end; ++t)
|
|
|
|
++total;
|
|
|
|
}
|
2014-08-25 19:26:06 +02:00
|
|
|
|
2014-08-25 19:26:03 +02:00
|
|
|
/* Perform the upgrade in a transaction. */
|
|
|
|
db->begin_transaction (true);
|
|
|
|
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
/* Set the target features so we write out changes in the desired
|
|
|
|
* format. */
|
2014-08-25 19:26:04 +02:00
|
|
|
notmuch->features = target_features;
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
|
2014-08-25 19:26:05 +02:00
|
|
|
/* Perform per-message upgrades. */
|
|
|
|
if (new_features &
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
(NOTMUCH_FEATURE_FILE_TERMS | NOTMUCH_FEATURE_BOOL_FOLDER |
|
|
|
|
NOTMUCH_FEATURE_LAST_MOD)) {
|
2010-01-08 03:26:31 +01:00
|
|
|
notmuch_messages_t *messages;
|
|
|
|
notmuch_message_t *message;
|
2010-01-09 20:13:12 +01:00
|
|
|
char *filename;
|
2010-01-08 03:26:31 +01:00
|
|
|
|
2015-09-27 17:31:55 +02:00
|
|
|
query = notmuch_query_create (notmuch, "");
|
|
|
|
|
2015-09-27 17:32:01 +02:00
|
|
|
status = notmuch_query_search_messages_st (query, &messages);
|
|
|
|
if (status)
|
|
|
|
goto DONE;
|
|
|
|
for (;
|
2010-03-09 18:22:29 +01:00
|
|
|
notmuch_messages_valid (messages);
|
|
|
|
notmuch_messages_move_to_next (messages))
|
2010-01-08 03:26:31 +01:00
|
|
|
{
|
2010-01-08 06:24:44 +01:00
|
|
|
if (do_progress_notify) {
|
2010-01-10 02:38:23 +01:00
|
|
|
progress_notify (closure, (double) count / total);
|
2010-01-08 06:24:44 +01:00
|
|
|
do_progress_notify = 0;
|
|
|
|
}
|
2010-01-08 03:26:31 +01:00
|
|
|
|
|
|
|
message = notmuch_messages_get (messages);
|
|
|
|
|
2014-08-25 19:26:05 +02:00
|
|
|
/* Before version 1, each message document had its
|
|
|
|
* filename in the data field. Copy that into the new
|
|
|
|
* format by calling notmuch_message_add_filename.
|
|
|
|
*/
|
|
|
|
if (new_features & NOTMUCH_FEATURE_FILE_TERMS) {
|
|
|
|
filename = _notmuch_message_talloc_copy_data (message);
|
|
|
|
if (filename && *filename != '\0') {
|
|
|
|
_notmuch_message_add_filename (message, filename);
|
|
|
|
_notmuch_message_clear_data (message);
|
|
|
|
}
|
|
|
|
talloc_free (filename);
|
2010-01-09 20:13:12 +01:00
|
|
|
}
|
2014-08-25 19:26:05 +02:00
|
|
|
|
|
|
|
/* Prior to version 2, the "folder:" prefix was
|
|
|
|
* probabilistic and stemmed. Change it to the current
|
|
|
|
* boolean prefix. Add "path:" prefixes while at it.
|
|
|
|
*/
|
|
|
|
if (new_features & NOTMUCH_FEATURE_BOOL_FOLDER)
|
|
|
|
_notmuch_message_upgrade_folder (message);
|
|
|
|
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
/* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
|
|
|
|
* track modification revisions. Give all messages the
|
|
|
|
* next available revision; since we just started tracking
|
|
|
|
* revisions for this database, that will be 1.
|
|
|
|
*/
|
|
|
|
if (new_features & NOTMUCH_FEATURE_LAST_MOD)
|
|
|
|
_notmuch_message_upgrade_last_mod (message);
|
|
|
|
|
2014-08-25 19:26:05 +02:00
|
|
|
_notmuch_message_sync (message);
|
2010-01-09 20:13:12 +01:00
|
|
|
|
|
|
|
notmuch_message_destroy (message);
|
2010-01-08 03:26:31 +01:00
|
|
|
|
|
|
|
count++;
|
|
|
|
}
|
2010-01-09 20:13:12 +01:00
|
|
|
|
|
|
|
notmuch_query_destroy (query);
|
2015-09-27 17:31:57 +02:00
|
|
|
query = NULL;
|
2014-08-25 19:26:04 +02:00
|
|
|
}
|
2010-01-08 03:26:31 +01:00
|
|
|
|
2014-08-25 19:26:05 +02:00
|
|
|
/* Perform per-directory upgrades. */
|
|
|
|
|
|
|
|
/* Before version 1 we stored directory timestamps in
|
2014-08-25 19:26:04 +02:00
|
|
|
* XTIMESTAMP documents instead of the current XDIRECTORY
|
|
|
|
* documents. So copy those as well. */
|
|
|
|
if (new_features & NOTMUCH_FEATURE_DIRECTORY_DOCS) {
|
2010-01-08 03:26:31 +01:00
|
|
|
t_end = notmuch->xapian_db->allterms_end ("XTIMESTAMP");
|
|
|
|
|
|
|
|
for (t = notmuch->xapian_db->allterms_begin ("XTIMESTAMP");
|
|
|
|
t != t_end;
|
|
|
|
t++)
|
|
|
|
{
|
|
|
|
Xapian::PostingIterator p, p_end;
|
|
|
|
std::string term = *t;
|
|
|
|
|
|
|
|
p_end = notmuch->xapian_db->postlist_end (term);
|
|
|
|
|
|
|
|
for (p = notmuch->xapian_db->postlist_begin (term);
|
|
|
|
p != p_end;
|
|
|
|
p++)
|
|
|
|
{
|
|
|
|
Xapian::Document document;
|
|
|
|
time_t mtime;
|
|
|
|
notmuch_directory_t *directory;
|
|
|
|
|
2010-01-10 02:38:23 +01:00
|
|
|
if (do_progress_notify) {
|
|
|
|
progress_notify (closure, (double) count / total);
|
|
|
|
do_progress_notify = 0;
|
|
|
|
}
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
document = find_document_for_doc_id (notmuch, *p);
|
|
|
|
mtime = Xapian::sortable_unserialise (
|
|
|
|
document.get_value (NOTMUCH_VALUE_TIMESTAMP));
|
|
|
|
|
2012-05-14 01:36:09 +02:00
|
|
|
directory = _notmuch_directory_create (notmuch, term.c_str() + 10,
|
2012-05-18 06:13:34 +02:00
|
|
|
NOTMUCH_FIND_CREATE, &status);
|
2010-01-08 03:26:31 +01:00
|
|
|
notmuch_directory_set_mtime (directory, mtime);
|
|
|
|
notmuch_directory_destroy (directory);
|
2014-08-25 19:26:03 +02:00
|
|
|
|
|
|
|
db->delete_document (*p);
|
2010-01-08 03:26:31 +01:00
|
|
|
}
|
2014-08-25 19:26:06 +02:00
|
|
|
|
|
|
|
++count;
|
2010-01-08 03:26:31 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-23 14:30:38 +02:00
|
|
|
/* Perform metadata upgrades. */
|
|
|
|
|
|
|
|
/* Prior to NOTMUCH_FEATURE_GHOSTS, thread IDs for missing
|
|
|
|
* messages were stored as database metadata. Change these to
|
|
|
|
* ghost messages.
|
|
|
|
*/
|
|
|
|
if (new_features & NOTMUCH_FEATURE_GHOSTS) {
|
|
|
|
notmuch_message_t *message;
|
|
|
|
std::string message_id, thread_id;
|
|
|
|
|
|
|
|
t_end = db->metadata_keys_end (NOTMUCH_METADATA_THREAD_ID_PREFIX);
|
|
|
|
for (t = db->metadata_keys_begin (NOTMUCH_METADATA_THREAD_ID_PREFIX);
|
|
|
|
t != t_end; ++t) {
|
|
|
|
if (do_progress_notify) {
|
|
|
|
progress_notify (closure, (double) count / total);
|
|
|
|
do_progress_notify = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
message_id = (*t).substr (
|
|
|
|
strlen (NOTMUCH_METADATA_THREAD_ID_PREFIX));
|
|
|
|
thread_id = db->get_metadata (*t);
|
|
|
|
|
|
|
|
/* Create ghost message */
|
|
|
|
message = _notmuch_message_create_for_message_id (
|
|
|
|
notmuch, message_id.c_str (), &private_status);
|
|
|
|
if (private_status == NOTMUCH_PRIVATE_STATUS_SUCCESS) {
|
|
|
|
/* Document already exists; ignore the stored thread ID */
|
|
|
|
} else if (private_status ==
|
|
|
|
NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND) {
|
|
|
|
private_status = _notmuch_message_initialize_ghost (
|
|
|
|
message, thread_id.c_str ());
|
|
|
|
if (! private_status)
|
|
|
|
_notmuch_message_sync (message);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (private_status) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch,
|
2014-10-23 14:30:38 +02:00
|
|
|
"Upgrade failed while creating ghost messages.\n");
|
|
|
|
status = COERCE_STATUS (private_status, "Unexpected status from _notmuch_message_initialize_ghost");
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear saved metadata thread ID */
|
|
|
|
db->set_metadata (*t, "");
|
|
|
|
|
|
|
|
++count;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
status = NOTMUCH_STATUS_SUCCESS;
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
db->set_metadata ("features", _print_features (local, notmuch->features));
|
2010-01-08 03:26:31 +01:00
|
|
|
db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
|
2010-01-09 20:13:12 +01:00
|
|
|
|
2014-10-23 14:30:38 +02:00
|
|
|
DONE:
|
|
|
|
if (status == NOTMUCH_STATUS_SUCCESS)
|
|
|
|
db->commit_transaction ();
|
|
|
|
else
|
|
|
|
db->cancel_transaction ();
|
2010-01-09 20:13:12 +01:00
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
if (timer_is_active) {
|
|
|
|
/* Now stop the timer. */
|
|
|
|
timerval.it_interval.tv_sec = 0;
|
|
|
|
timerval.it_interval.tv_usec = 0;
|
|
|
|
timerval.it_value.tv_sec = 0;
|
|
|
|
timerval.it_value.tv_usec = 0;
|
|
|
|
setitimer (ITIMER_REAL, &timerval, NULL);
|
|
|
|
|
|
|
|
/* And disable the signal handler. */
|
|
|
|
action.sa_handler = SIG_IGN;
|
|
|
|
sigaction (SIGALRM, &action, NULL);
|
|
|
|
}
|
|
|
|
|
2015-09-27 17:31:57 +02:00
|
|
|
if (query)
|
|
|
|
notmuch_query_destroy (query);
|
|
|
|
|
lib: Database version 3: Introduce fine-grained "features"
Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1. Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series. This made introducing a new schema
version hard. We've seen only two schema changes in the history of
Notmuch.
This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while. With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.
Features should make backwards compatibility easier. For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.
Features also make forwards compatibility easier. The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write. This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors. If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all. If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
2014-08-25 19:26:00 +02:00
|
|
|
talloc_free (local);
|
2014-10-23 14:30:38 +02:00
|
|
|
return status;
|
2010-01-08 03:26:31 +01:00
|
|
|
}
|
|
|
|
|
2011-01-29 17:25:24 +01:00
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_begin_atomic (notmuch_database_t *notmuch)
|
|
|
|
{
|
2011-06-11 05:35:06 +02:00
|
|
|
if (notmuch->mode == NOTMUCH_DATABASE_MODE_READ_ONLY ||
|
|
|
|
notmuch->atomic_nesting > 0)
|
|
|
|
goto DONE;
|
2011-01-29 17:25:24 +01:00
|
|
|
|
2016-09-27 17:06:52 +02:00
|
|
|
if (notmuch_database_needs_upgrade (notmuch))
|
|
|
|
return NOTMUCH_STATUS_UPGRADE_REQUIRED;
|
2015-10-25 22:30:39 +01:00
|
|
|
|
2011-01-29 17:25:24 +01:00
|
|
|
try {
|
|
|
|
(static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db))->begin_transaction (false);
|
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "A Xapian exception occurred beginning transaction: %s.\n",
|
2011-01-29 17:25:24 +01:00
|
|
|
error.get_msg().c_str());
|
|
|
|
notmuch->exception_reported = TRUE;
|
|
|
|
return NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
}
|
2011-06-11 05:35:06 +02:00
|
|
|
|
|
|
|
DONE:
|
|
|
|
notmuch->atomic_nesting++;
|
2011-01-29 17:25:24 +01:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_end_atomic (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
Xapian::WritableDatabase *db;
|
|
|
|
|
2011-06-11 05:35:06 +02:00
|
|
|
if (notmuch->atomic_nesting == 0)
|
|
|
|
return NOTMUCH_STATUS_UNBALANCED_ATOMIC;
|
|
|
|
|
|
|
|
if (notmuch->mode == NOTMUCH_DATABASE_MODE_READ_ONLY ||
|
|
|
|
notmuch->atomic_nesting > 1)
|
|
|
|
goto DONE;
|
2011-01-29 17:25:24 +01:00
|
|
|
|
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
try {
|
|
|
|
db->commit_transaction ();
|
|
|
|
|
|
|
|
/* This is a hack for testing. Xapian never flushes on a
|
|
|
|
* non-flushed commit, even if the flush threshold is 1.
|
|
|
|
* However, we rely on flushing to test atomicity. */
|
|
|
|
const char *thresh = getenv ("XAPIAN_FLUSH_THRESHOLD");
|
|
|
|
if (thresh && atoi (thresh) == 1)
|
2016-10-05 13:34:33 +02:00
|
|
|
db->commit ();
|
2011-01-29 17:25:24 +01:00
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "A Xapian exception occurred committing transaction: %s.\n",
|
2011-01-29 17:25:24 +01:00
|
|
|
error.get_msg().c_str());
|
|
|
|
notmuch->exception_reported = TRUE;
|
|
|
|
return NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
}
|
2011-06-11 05:35:06 +02:00
|
|
|
|
lib: Add per-message last modification tracking
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.
2014-10-13 08:20:01 +02:00
|
|
|
if (notmuch->atomic_dirty) {
|
|
|
|
++notmuch->revision;
|
|
|
|
notmuch->atomic_dirty = FALSE;
|
|
|
|
}
|
|
|
|
|
2011-06-11 05:35:06 +02:00
|
|
|
DONE:
|
|
|
|
notmuch->atomic_nesting--;
|
2011-01-29 17:25:24 +01:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2014-10-13 08:20:02 +02:00
|
|
|
unsigned long
|
|
|
|
notmuch_database_get_revision (notmuch_database_t *notmuch,
|
|
|
|
const char **uuid)
|
|
|
|
{
|
|
|
|
if (uuid)
|
|
|
|
*uuid = notmuch->uuid;
|
|
|
|
return notmuch->revision;
|
|
|
|
}
|
|
|
|
|
2009-12-17 23:33:34 +01:00
|
|
|
/* We allow the user to use arbitrarily long paths for directories. But
|
|
|
|
* we have a term-length limit. So if we exceed that, we'll use the
|
|
|
|
* SHA-1 of the path for the database term.
|
2009-10-23 23:31:01 +02:00
|
|
|
*
|
2009-12-17 23:33:34 +01:00
|
|
|
* Note: This function may return the original value of 'path'. If it
|
|
|
|
* does not, then the caller is responsible to free() the returned
|
|
|
|
* value.
|
2009-10-23 23:31:01 +02:00
|
|
|
*/
|
2010-01-05 22:29:23 +01:00
|
|
|
const char *
|
|
|
|
_notmuch_database_get_directory_db_path (const char *path)
|
2009-10-23 23:31:01 +02:00
|
|
|
{
|
2009-12-17 23:33:34 +01:00
|
|
|
int term_len = strlen (_find_prefix ("directory")) + strlen (path);
|
2009-10-25 06:10:03 +01:00
|
|
|
|
|
|
|
if (term_len > NOTMUCH_TERM_MAX)
|
2014-05-13 11:44:05 +02:00
|
|
|
return _notmuch_sha1_of_string (path);
|
2009-10-25 06:10:03 +01:00
|
|
|
else
|
2009-12-17 23:33:34 +01:00
|
|
|
return path;
|
2009-10-23 23:31:01 +02:00
|
|
|
}
|
|
|
|
|
2009-12-21 17:14:52 +01:00
|
|
|
/* Given a path, split it into two parts: the directory part is all
|
|
|
|
* components except for the last, and the basename is that last
|
|
|
|
* component. Getting the return-value for either part is optional
|
|
|
|
* (the caller can pass NULL).
|
2009-12-20 00:11:55 +01:00
|
|
|
*
|
|
|
|
* The original 'path' can represent either a regular file or a
|
2009-12-21 17:14:52 +01:00
|
|
|
* directory---the splitting will be carried out in the same way in
|
|
|
|
* either case. Trailing slashes on 'path' will be ignored, and any
|
2009-12-20 00:11:55 +01:00
|
|
|
* cases of multiple '/' characters appearing in series will be
|
|
|
|
* treated as a single '/'.
|
|
|
|
*
|
2009-12-21 17:14:52 +01:00
|
|
|
* Allocation (if any) will have 'ctx' as the talloc owner. But
|
|
|
|
* pointers will be returned within the original path string whenever
|
|
|
|
* possible.
|
2009-12-20 00:11:55 +01:00
|
|
|
*
|
2009-12-21 17:14:52 +01:00
|
|
|
* Note: If 'path' is non-empty and contains no non-trailing slash,
|
|
|
|
* (that is, consists of a filename with no parent directory), then
|
|
|
|
* the directory returned will be an empty string. However, if 'path'
|
|
|
|
* is an empty string, then both directory and basename will be
|
|
|
|
* returned as NULL.
|
2009-12-20 00:11:55 +01:00
|
|
|
*/
|
2009-12-19 22:20:26 +01:00
|
|
|
notmuch_status_t
|
2009-12-21 17:14:52 +01:00
|
|
|
_notmuch_database_split_path (void *ctx,
|
|
|
|
const char *path,
|
|
|
|
const char **directory,
|
|
|
|
const char **basename)
|
2009-12-19 22:20:26 +01:00
|
|
|
{
|
2009-12-21 17:14:52 +01:00
|
|
|
const char *slash;
|
2009-12-19 22:20:26 +01:00
|
|
|
|
|
|
|
if (path == NULL || *path == '\0') {
|
2009-12-21 17:14:52 +01:00
|
|
|
if (directory)
|
|
|
|
*directory = NULL;
|
|
|
|
if (basename)
|
|
|
|
*basename = NULL;
|
2009-12-19 22:20:26 +01:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Find the last slash (not counting a trailing slash), if any. */
|
|
|
|
|
|
|
|
slash = path + strlen (path) - 1;
|
|
|
|
|
|
|
|
/* First, skip trailing slashes. */
|
2016-04-10 21:43:23 +02:00
|
|
|
while (slash != path && *slash == '/')
|
2009-12-19 22:20:26 +01:00
|
|
|
--slash;
|
|
|
|
|
|
|
|
/* Then, find a slash. */
|
2016-04-10 21:43:23 +02:00
|
|
|
while (slash != path && *slash != '/') {
|
2009-12-21 17:14:52 +01:00
|
|
|
if (basename)
|
|
|
|
*basename = slash;
|
|
|
|
|
2009-12-19 22:20:26 +01:00
|
|
|
--slash;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Finally, skip multiple slashes. */
|
2016-04-10 21:43:23 +02:00
|
|
|
while (slash != path && *(slash - 1) == '/')
|
2009-12-19 22:20:26 +01:00
|
|
|
--slash;
|
|
|
|
|
2009-12-21 17:14:52 +01:00
|
|
|
if (slash == path) {
|
|
|
|
if (directory)
|
|
|
|
*directory = talloc_strdup (ctx, "");
|
|
|
|
if (basename)
|
|
|
|
*basename = path;
|
|
|
|
} else {
|
|
|
|
if (directory)
|
2016-04-10 21:43:22 +02:00
|
|
|
*directory = talloc_strndup (ctx, path, slash - path);
|
2009-12-21 17:14:52 +01:00
|
|
|
}
|
2009-12-19 22:20:26 +01:00
|
|
|
|
2009-12-21 17:14:52 +01:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-05-18 06:13:35 +02:00
|
|
|
/* Find the document ID of the specified directory.
|
|
|
|
*
|
|
|
|
* If (flags & NOTMUCH_FIND_CREATE), a new directory document will be
|
|
|
|
* created if one does not exist for 'path'. Otherwise, if the
|
|
|
|
* directory document does not exist, this sets *directory_id to
|
|
|
|
* ((unsigned int)-1) and returns NOTMUCH_STATUS_SUCCESS.
|
|
|
|
*/
|
2009-12-21 17:14:52 +01:00
|
|
|
notmuch_status_t
|
|
|
|
_notmuch_database_find_directory_id (notmuch_database_t *notmuch,
|
|
|
|
const char *path,
|
2012-05-18 06:13:35 +02:00
|
|
|
notmuch_find_flags_t flags,
|
2009-12-21 17:14:52 +01:00
|
|
|
unsigned int *directory_id)
|
|
|
|
{
|
2010-01-05 22:29:23 +01:00
|
|
|
notmuch_directory_t *directory;
|
|
|
|
notmuch_status_t status;
|
2009-12-21 17:14:52 +01:00
|
|
|
|
|
|
|
if (path == NULL) {
|
|
|
|
*directory_id = 0;
|
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2012-05-18 06:13:35 +02:00
|
|
|
directory = _notmuch_directory_create (notmuch, path, flags, &status);
|
|
|
|
if (status || !directory) {
|
2010-01-05 22:29:23 +01:00
|
|
|
*directory_id = -1;
|
|
|
|
return status;
|
2009-12-19 22:20:26 +01:00
|
|
|
}
|
|
|
|
|
2010-01-05 22:29:23 +01:00
|
|
|
*directory_id = _notmuch_directory_get_document_id (directory);
|
2009-12-19 22:20:26 +01:00
|
|
|
|
2010-01-05 22:29:23 +01:00
|
|
|
notmuch_directory_destroy (directory);
|
2009-12-20 00:11:55 +01:00
|
|
|
|
2010-01-05 22:29:23 +01:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
2009-12-19 22:20:26 +01:00
|
|
|
}
|
|
|
|
|
2009-12-21 17:23:26 +01:00
|
|
|
const char *
|
|
|
|
_notmuch_database_get_directory_path (void *ctx,
|
|
|
|
notmuch_database_t *notmuch,
|
|
|
|
unsigned int doc_id)
|
|
|
|
{
|
|
|
|
Xapian::Document document;
|
|
|
|
|
|
|
|
document = find_document_for_doc_id (notmuch, doc_id);
|
|
|
|
|
|
|
|
return talloc_strdup (ctx, document.get_data ().c_str ());
|
|
|
|
}
|
|
|
|
|
2009-12-22 00:09:56 +01:00
|
|
|
/* Given a legal 'filename' for the database, (either relative to
|
|
|
|
* database path or absolute with initial components identical to
|
|
|
|
* database path), return a new string (with 'ctx' as the talloc
|
|
|
|
* owner) suitable for use as a direntry term value.
|
2010-01-07 18:31:58 +01:00
|
|
|
*
|
2012-05-18 06:13:36 +02:00
|
|
|
* If (flags & NOTMUCH_FIND_CREATE), the necessary directory documents
|
|
|
|
* will be created in the database as needed. Otherwise, if the
|
|
|
|
* necessary directory documents do not exist, this sets
|
|
|
|
* *direntry to NULL and returns NOTMUCH_STATUS_SUCCESS.
|
2009-12-22 00:09:56 +01:00
|
|
|
*/
|
|
|
|
notmuch_status_t
|
|
|
|
_notmuch_database_filename_to_direntry (void *ctx,
|
|
|
|
notmuch_database_t *notmuch,
|
|
|
|
const char *filename,
|
2012-05-18 06:13:36 +02:00
|
|
|
notmuch_find_flags_t flags,
|
2009-12-22 00:09:56 +01:00
|
|
|
char **direntry)
|
|
|
|
{
|
|
|
|
const char *relative, *directory, *basename;
|
|
|
|
Xapian::docid directory_id;
|
|
|
|
notmuch_status_t status;
|
|
|
|
|
|
|
|
relative = _notmuch_database_relative_path (notmuch, filename);
|
|
|
|
|
|
|
|
status = _notmuch_database_split_path (ctx, relative,
|
|
|
|
&directory, &basename);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
2012-05-18 06:13:36 +02:00
|
|
|
status = _notmuch_database_find_directory_id (notmuch, directory, flags,
|
2009-12-22 00:09:56 +01:00
|
|
|
&directory_id);
|
2012-05-18 06:13:36 +02:00
|
|
|
if (status || directory_id == (unsigned int)-1) {
|
|
|
|
*direntry = NULL;
|
2009-12-22 00:09:56 +01:00
|
|
|
return status;
|
2012-05-18 06:13:36 +02:00
|
|
|
}
|
2009-12-22 00:09:56 +01:00
|
|
|
|
|
|
|
*direntry = talloc_asprintf (ctx, "%u:%s", directory_id, basename);
|
|
|
|
|
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2009-12-19 21:32:11 +01:00
|
|
|
/* Given a legal 'path' for the database, return the relative path.
|
|
|
|
*
|
2011-06-20 22:14:21 +02:00
|
|
|
* The return value will be a pointer to the original path contents,
|
2009-12-19 21:32:11 +01:00
|
|
|
* and will be either the original string (if 'path' was relative) or
|
|
|
|
* a portion of the string (if path was absolute and begins with the
|
|
|
|
* database path).
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
_notmuch_database_relative_path (notmuch_database_t *notmuch,
|
|
|
|
const char *path)
|
|
|
|
{
|
|
|
|
const char *db_path, *relative;
|
|
|
|
unsigned int db_path_len;
|
|
|
|
|
|
|
|
db_path = notmuch_database_get_path (notmuch);
|
|
|
|
db_path_len = strlen (db_path);
|
|
|
|
|
|
|
|
relative = path;
|
|
|
|
|
|
|
|
if (*relative == '/') {
|
|
|
|
while (*relative == '/' && *(relative+1) == '/')
|
|
|
|
relative++;
|
|
|
|
|
|
|
|
if (strncmp (relative, db_path, db_path_len) == 0)
|
|
|
|
{
|
|
|
|
relative += db_path_len;
|
|
|
|
while (*relative == '/')
|
|
|
|
relative++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return relative;
|
|
|
|
}
|
|
|
|
|
2012-05-14 01:36:09 +02:00
|
|
|
notmuch_status_t
|
2010-01-05 22:29:23 +01:00
|
|
|
notmuch_database_get_directory (notmuch_database_t *notmuch,
|
2012-05-14 01:36:09 +02:00
|
|
|
const char *path,
|
|
|
|
notmuch_directory_t **directory)
|
2009-10-23 23:31:01 +02:00
|
|
|
{
|
2010-01-05 22:29:23 +01:00
|
|
|
notmuch_status_t status;
|
2009-10-23 23:31:01 +02:00
|
|
|
|
2012-05-14 01:36:09 +02:00
|
|
|
if (directory == NULL)
|
|
|
|
return NOTMUCH_STATUS_NULL_POINTER;
|
|
|
|
*directory = NULL;
|
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
try {
|
2012-05-18 06:13:37 +02:00
|
|
|
*directory = _notmuch_directory_create (notmuch, path,
|
|
|
|
NOTMUCH_FIND_LOOKUP, &status);
|
2010-04-24 16:22:34 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "A Xapian exception occurred getting directory: %s.\n",
|
2010-04-24 16:22:34 +02:00
|
|
|
error.get_msg().c_str());
|
|
|
|
notmuch->exception_reported = TRUE;
|
2012-05-14 01:36:09 +02:00
|
|
|
status = NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
2010-04-24 16:22:34 +02:00
|
|
|
}
|
2012-05-14 01:36:09 +02:00
|
|
|
return status;
|
2009-10-23 23:31:01 +02:00
|
|
|
}
|
|
|
|
|
2010-06-04 19:16:53 +02:00
|
|
|
/* Allocate a document ID that satisfies the following criteria:
|
|
|
|
*
|
|
|
|
* 1. The ID does not exist for any document in the Xapian database
|
|
|
|
*
|
|
|
|
* 2. The ID was not previously returned from this function
|
|
|
|
*
|
|
|
|
* 3. The ID is the smallest integer satisfying (1) and (2)
|
|
|
|
*
|
|
|
|
* This function will trigger an internal error if these constraints
|
|
|
|
* cannot all be satisfied, (that is, the pool of available document
|
|
|
|
* IDs has been exhausted).
|
|
|
|
*/
|
|
|
|
unsigned int
|
|
|
|
_notmuch_database_generate_doc_id (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
assert (notmuch->last_doc_id >= notmuch->xapian_db->get_lastdocid ());
|
|
|
|
|
|
|
|
notmuch->last_doc_id++;
|
|
|
|
|
|
|
|
if (notmuch->last_doc_id == 0)
|
2013-11-13 18:02:43 +01:00
|
|
|
INTERNAL_ERROR ("Xapian document IDs are exhausted.\n");
|
2010-06-04 19:16:53 +02:00
|
|
|
|
|
|
|
return notmuch->last_doc_id;
|
|
|
|
}
|
|
|
|
|
2010-03-13 22:27:57 +01:00
|
|
|
static const char *
|
|
|
|
_notmuch_database_generate_thread_id (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
/* 16 bytes (+ terminator) for hexadecimal representation of
|
|
|
|
* a 64-bit integer. */
|
|
|
|
static char thread_id[17];
|
|
|
|
Xapian::WritableDatabase *db;
|
|
|
|
|
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
|
|
|
|
notmuch->last_thread_id++;
|
|
|
|
|
|
|
|
sprintf (thread_id, "%016" PRIx64, notmuch->last_thread_id);
|
|
|
|
|
|
|
|
db->set_metadata ("last_thread_id", thread_id);
|
|
|
|
|
|
|
|
return thread_id;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *
|
|
|
|
_get_metadata_thread_id_key (void *ctx, const char *message_id)
|
|
|
|
{
|
2010-06-04 21:39:36 +02:00
|
|
|
if (strlen (message_id) > NOTMUCH_MESSAGE_ID_MAX)
|
2014-10-07 01:17:07 +02:00
|
|
|
message_id = _notmuch_message_id_compressed (ctx, message_id);
|
2010-06-04 21:39:36 +02:00
|
|
|
|
|
|
|
return talloc_asprintf (ctx, NOTMUCH_METADATA_THREAD_ID_PREFIX "%s",
|
|
|
|
message_id);
|
2010-03-13 22:27:57 +01:00
|
|
|
}
|
|
|
|
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
static notmuch_status_t
|
|
|
|
_resolve_message_id_to_thread_id_old (notmuch_database_t *notmuch,
|
|
|
|
void *ctx,
|
|
|
|
const char *message_id,
|
|
|
|
const char **thread_id_ret);
|
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
/* Find the thread ID to which the message with 'message_id' belongs.
|
2009-10-25 19:03:55 +01:00
|
|
|
*
|
2011-10-04 06:55:29 +02:00
|
|
|
* Note: 'thread_id_ret' must not be NULL!
|
|
|
|
* On success '*thread_id_ret' is set to a newly talloced string belonging to
|
|
|
|
* 'ctx'.
|
2009-10-25 19:03:55 +01:00
|
|
|
*
|
2010-04-12 23:19:15 +02:00
|
|
|
* Note: If there is no message in the database with the given
|
|
|
|
* 'message_id' then a new thread_id will be allocated for this
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
* message ID and stored in the database metadata so that the
|
2010-04-12 23:19:15 +02:00
|
|
|
* thread ID can be looked up if the message is added to the database
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
* later.
|
2009-10-25 19:03:55 +01:00
|
|
|
*/
|
2011-10-04 06:55:29 +02:00
|
|
|
static notmuch_status_t
|
2009-10-25 22:54:13 +01:00
|
|
|
_resolve_message_id_to_thread_id (notmuch_database_t *notmuch,
|
|
|
|
void *ctx,
|
2011-10-04 06:55:29 +02:00
|
|
|
const char *message_id,
|
|
|
|
const char **thread_id_ret)
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
{
|
|
|
|
notmuch_private_status_t status;
|
|
|
|
notmuch_message_t *message;
|
|
|
|
|
|
|
|
if (! (notmuch->features & NOTMUCH_FEATURE_GHOSTS))
|
|
|
|
return _resolve_message_id_to_thread_id_old (notmuch, ctx, message_id,
|
|
|
|
thread_id_ret);
|
|
|
|
|
|
|
|
/* Look for this message (regular or ghost) */
|
|
|
|
message = _notmuch_message_create_for_message_id (
|
|
|
|
notmuch, message_id, &status);
|
|
|
|
if (status == NOTMUCH_PRIVATE_STATUS_SUCCESS) {
|
|
|
|
/* Message exists */
|
|
|
|
*thread_id_ret = talloc_steal (
|
|
|
|
ctx, notmuch_message_get_thread_id (message));
|
|
|
|
} else if (status == NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND) {
|
|
|
|
/* Message did not exist. Give it a fresh thread ID and
|
|
|
|
* populate this message as a ghost message. */
|
|
|
|
*thread_id_ret = talloc_strdup (
|
|
|
|
ctx, _notmuch_database_generate_thread_id (notmuch));
|
|
|
|
if (! *thread_id_ret) {
|
|
|
|
status = NOTMUCH_PRIVATE_STATUS_OUT_OF_MEMORY;
|
|
|
|
} else {
|
|
|
|
status = _notmuch_message_initialize_ghost (message, *thread_id_ret);
|
|
|
|
if (status == 0)
|
|
|
|
/* Commit the new ghost message */
|
|
|
|
_notmuch_message_sync (message);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Create failed. Fall through. */
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
|
|
|
|
return COERCE_STATUS (status, "Error creating ghost message");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Pre-ghost messages _resolve_message_id_to_thread_id */
|
|
|
|
static notmuch_status_t
|
|
|
|
_resolve_message_id_to_thread_id_old (notmuch_database_t *notmuch,
|
|
|
|
void *ctx,
|
|
|
|
const char *message_id,
|
|
|
|
const char **thread_id_ret)
|
2009-10-25 22:54:13 +01:00
|
|
|
{
|
2011-10-04 06:55:29 +02:00
|
|
|
notmuch_status_t status;
|
2009-10-25 22:54:13 +01:00
|
|
|
notmuch_message_t *message;
|
2010-04-12 23:29:36 +02:00
|
|
|
string thread_id_string;
|
|
|
|
char *metadata_key;
|
|
|
|
Xapian::WritableDatabase *db;
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
status = notmuch_database_find_message (notmuch, message_id, &message);
|
|
|
|
|
|
|
|
if (status)
|
|
|
|
return status;
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2010-04-12 23:29:36 +02:00
|
|
|
if (message) {
|
2011-10-04 06:55:29 +02:00
|
|
|
*thread_id_ret = talloc_steal (ctx,
|
|
|
|
notmuch_message_get_thread_id (message));
|
2009-10-25 22:54:13 +01:00
|
|
|
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
2010-04-12 23:29:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Message has not been seen yet.
|
|
|
|
*
|
|
|
|
* We may have seen a reference to it already, in which case, we
|
|
|
|
* can return the thread ID stored in the metadata. Otherwise, we
|
|
|
|
* generate a new thread ID and store it there.
|
|
|
|
*/
|
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
metadata_key = _get_metadata_thread_id_key (ctx, message_id);
|
|
|
|
thread_id_string = notmuch->xapian_db->get_metadata (metadata_key);
|
|
|
|
|
|
|
|
if (thread_id_string.empty()) {
|
2011-10-04 06:55:29 +02:00
|
|
|
*thread_id_ret = talloc_strdup (ctx,
|
|
|
|
_notmuch_database_generate_thread_id (notmuch));
|
|
|
|
db->set_metadata (metadata_key, *thread_id_ret);
|
2010-04-12 23:29:36 +02:00
|
|
|
} else {
|
2011-10-04 06:55:29 +02:00
|
|
|
*thread_id_ret = talloc_strdup (ctx, thread_id_string.c_str());
|
2010-04-12 23:29:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
talloc_free (metadata_key);
|
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
2009-10-25 22:54:13 +01:00
|
|
|
}
|
|
|
|
|
2009-10-25 19:03:55 +01:00
|
|
|
static notmuch_status_t
|
2009-10-25 22:54:13 +01:00
|
|
|
_merge_threads (notmuch_database_t *notmuch,
|
|
|
|
const char *winner_thread_id,
|
|
|
|
const char *loser_thread_id)
|
|
|
|
{
|
|
|
|
Xapian::PostingIterator loser, loser_end;
|
|
|
|
notmuch_message_t *message = NULL;
|
|
|
|
notmuch_private_status_t private_status;
|
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
|
|
|
|
|
|
|
|
find_doc_ids (notmuch, "thread", loser_thread_id, &loser, &loser_end);
|
|
|
|
|
|
|
|
for ( ; loser != loser_end; loser++) {
|
|
|
|
message = _notmuch_message_create (notmuch, notmuch,
|
|
|
|
*loser, &private_status);
|
|
|
|
if (message == NULL) {
|
|
|
|
ret = COERCE_STATUS (private_status,
|
|
|
|
"Cannot find document for doc_id from query");
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
_notmuch_message_remove_term (message, "thread", loser_thread_id);
|
|
|
|
_notmuch_message_add_term (message, "thread", winner_thread_id);
|
|
|
|
_notmuch_message_sync (message);
|
|
|
|
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
message = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
DONE:
|
|
|
|
if (message)
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
static void
|
|
|
|
_my_talloc_free_for_g_hash (void *ptr)
|
|
|
|
{
|
|
|
|
talloc_free (ptr);
|
|
|
|
}
|
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
static notmuch_status_t
|
|
|
|
_notmuch_database_link_message_to_parents (notmuch_database_t *notmuch,
|
|
|
|
notmuch_message_t *message,
|
|
|
|
notmuch_message_file_t *message_file,
|
|
|
|
const char **thread_id)
|
2009-10-25 19:03:55 +01:00
|
|
|
{
|
2009-10-25 22:54:13 +01:00
|
|
|
GHashTable *parents = NULL;
|
2009-11-18 02:20:32 +01:00
|
|
|
const char *refs, *in_reply_to, *in_reply_to_message_id;
|
2013-03-06 04:31:49 +01:00
|
|
|
const char *last_ref_message_id, *this_message_id;
|
2009-10-25 22:54:13 +01:00
|
|
|
GList *l, *keys = NULL;
|
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
parents = g_hash_table_new_full (g_str_hash, g_str_equal,
|
2009-10-26 23:17:10 +01:00
|
|
|
_my_talloc_free_for_g_hash, NULL);
|
2013-03-06 04:31:49 +01:00
|
|
|
this_message_id = notmuch_message_get_message_id (message);
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2014-05-13 11:44:05 +02:00
|
|
|
refs = _notmuch_message_file_get_header (message_file, "references");
|
2013-03-06 04:31:49 +01:00
|
|
|
last_ref_message_id = parse_references (message,
|
|
|
|
this_message_id,
|
|
|
|
parents, refs);
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2014-05-13 11:44:05 +02:00
|
|
|
in_reply_to = _notmuch_message_file_get_header (message_file, "in-reply-to");
|
2013-03-06 04:31:49 +01:00
|
|
|
in_reply_to_message_id = parse_references (message,
|
|
|
|
this_message_id,
|
|
|
|
parents, in_reply_to);
|
|
|
|
|
|
|
|
/* For the parent of this message, use the last message ID of the
|
|
|
|
* References header, if available. If not, fall back to the
|
|
|
|
* first message ID in the In-Reply-To header. */
|
|
|
|
if (last_ref_message_id) {
|
2016-05-28 19:45:31 +02:00
|
|
|
_notmuch_message_add_term (message, "replyto",
|
|
|
|
last_ref_message_id);
|
2013-03-06 04:31:49 +01:00
|
|
|
} else if (in_reply_to_message_id) {
|
2009-11-18 02:20:32 +01:00
|
|
|
_notmuch_message_add_term (message, "replyto",
|
2013-03-06 04:31:49 +01:00
|
|
|
in_reply_to_message_id);
|
2009-11-18 02:20:32 +01:00
|
|
|
}
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
keys = g_hash_table_get_keys (parents);
|
|
|
|
for (l = keys; l; l = l->next) {
|
|
|
|
char *parent_message_id;
|
2011-12-20 16:20:04 +01:00
|
|
|
const char *parent_thread_id = NULL;
|
2009-10-25 22:54:13 +01:00
|
|
|
|
|
|
|
parent_message_id = (char *) l->data;
|
2010-04-13 00:45:40 +02:00
|
|
|
|
|
|
|
_notmuch_message_add_term (message, "reference",
|
|
|
|
parent_message_id);
|
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
ret = _resolve_message_id_to_thread_id (notmuch,
|
|
|
|
message,
|
|
|
|
parent_message_id,
|
|
|
|
&parent_thread_id);
|
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2010-04-13 00:54:03 +02:00
|
|
|
if (*thread_id == NULL) {
|
|
|
|
*thread_id = talloc_strdup (message, parent_thread_id);
|
|
|
|
_notmuch_message_add_term (message, "thread", *thread_id);
|
|
|
|
} else if (strcmp (*thread_id, parent_thread_id)) {
|
|
|
|
ret = _merge_threads (notmuch, *thread_id, parent_thread_id);
|
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
2009-10-25 22:54:13 +01:00
|
|
|
}
|
|
|
|
}
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
DONE:
|
|
|
|
if (keys)
|
|
|
|
g_list_free (keys);
|
|
|
|
if (parents)
|
|
|
|
g_hash_table_unref (parents);
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
return ret;
|
|
|
|
}
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
static notmuch_status_t
|
|
|
|
_notmuch_database_link_message_to_children (notmuch_database_t *notmuch,
|
|
|
|
notmuch_message_t *message,
|
|
|
|
const char **thread_id)
|
|
|
|
{
|
|
|
|
const char *message_id = notmuch_message_get_message_id (message);
|
|
|
|
Xapian::PostingIterator child, children_end;
|
|
|
|
notmuch_message_t *child_message = NULL;
|
|
|
|
const char *child_thread_id;
|
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
|
|
|
|
notmuch_private_status_t private_status;
|
|
|
|
|
2009-11-18 03:44:02 +01:00
|
|
|
find_doc_ids (notmuch, "reference", message_id, &child, &children_end);
|
2009-10-25 22:54:13 +01:00
|
|
|
|
|
|
|
for ( ; child != children_end; child++) {
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
child_message = _notmuch_message_create (message, notmuch,
|
|
|
|
*child, &private_status);
|
|
|
|
if (child_message == NULL) {
|
|
|
|
ret = COERCE_STATUS (private_status,
|
|
|
|
"Cannot find document for doc_id from query");
|
|
|
|
goto DONE;
|
2009-10-25 19:03:55 +01:00
|
|
|
}
|
2009-10-25 22:54:13 +01:00
|
|
|
|
|
|
|
child_thread_id = notmuch_message_get_thread_id (child_message);
|
|
|
|
if (*thread_id == NULL) {
|
|
|
|
*thread_id = talloc_strdup (message, child_thread_id);
|
|
|
|
_notmuch_message_add_term (message, "thread", *thread_id);
|
|
|
|
} else if (strcmp (*thread_id, child_thread_id)) {
|
2009-11-18 03:44:02 +01:00
|
|
|
_notmuch_message_remove_term (child_message, "reference",
|
2009-10-25 22:54:13 +01:00
|
|
|
message_id);
|
|
|
|
_notmuch_message_sync (child_message);
|
|
|
|
ret = _merge_threads (notmuch, *thread_id, child_thread_id);
|
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_message_destroy (child_message);
|
|
|
|
child_message = NULL;
|
2009-10-25 19:03:55 +01:00
|
|
|
}
|
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
DONE:
|
|
|
|
if (child_message)
|
|
|
|
notmuch_message_destroy (child_message);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2014-10-07 01:17:08 +02:00
|
|
|
/* Fetch and clear the stored thread_id for message, or NULL if none. */
|
|
|
|
static char *
|
|
|
|
_consume_metadata_thread_id (void *ctx, notmuch_database_t *notmuch,
|
|
|
|
notmuch_message_t *message)
|
|
|
|
{
|
|
|
|
const char *message_id;
|
|
|
|
string stored_id;
|
|
|
|
char *metadata_key;
|
|
|
|
|
|
|
|
message_id = notmuch_message_get_message_id (message);
|
|
|
|
metadata_key = _get_metadata_thread_id_key (ctx, message_id);
|
|
|
|
|
|
|
|
/* Check if we have already seen related messages to this one.
|
|
|
|
* If we have then use the thread_id that we stored at that time.
|
|
|
|
*/
|
|
|
|
stored_id = notmuch->xapian_db->get_metadata (metadata_key);
|
|
|
|
if (stored_id.empty ()) {
|
|
|
|
return NULL;
|
|
|
|
} else {
|
2016-05-28 19:45:31 +02:00
|
|
|
Xapian::WritableDatabase *db;
|
2014-10-07 01:17:08 +02:00
|
|
|
|
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
|
|
|
|
/* Clear the metadata for this message ID. We don't need it
|
|
|
|
* anymore. */
|
2016-05-28 19:45:31 +02:00
|
|
|
db->set_metadata (metadata_key, "");
|
2014-10-07 01:17:08 +02:00
|
|
|
|
2016-05-28 19:45:31 +02:00
|
|
|
return talloc_strdup (ctx, stored_id.c_str ());
|
2014-10-07 01:17:08 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
/* Given a blank or ghost 'message' and its corresponding
|
2009-10-25 22:54:13 +01:00
|
|
|
* 'message_file' link it to existing threads in the database.
|
|
|
|
*
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
* First, if is_ghost, this retrieves the thread ID already stored in
|
|
|
|
* the message (which will be the case if a message was previously
|
|
|
|
* added that referenced this one). If the message is blank
|
|
|
|
* (!is_ghost), it doesn't have a thread ID yet (we'll generate one
|
|
|
|
* later in this function). If the database does not support ghost
|
|
|
|
* messages, this checks for a thread ID stored in database metadata
|
|
|
|
* for this message ID.
|
2010-04-12 23:35:25 +02:00
|
|
|
*
|
|
|
|
* Second, we look at 'message_file' and its link-relevant headers
|
|
|
|
* (References and In-Reply-To) for message IDs.
|
|
|
|
*
|
|
|
|
* Finally, we look in the database for existing message that
|
|
|
|
* reference 'message'.
|
|
|
|
*
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
* In all cases, we assign to the current message the first thread ID
|
2014-10-23 14:30:41 +02:00
|
|
|
* found. We will also merge any existing, distinct threads where this
|
|
|
|
* message belongs to both, (which is not uncommon when messages are
|
|
|
|
* processed out of order).
|
2009-10-25 22:54:13 +01:00
|
|
|
*
|
2014-10-23 14:30:41 +02:00
|
|
|
* Finally, if no thread ID has been found through referenced messages, we
|
2010-04-12 23:35:25 +02:00
|
|
|
* call _notmuch_message_generate_thread_id to generate a new thread
|
|
|
|
* ID. This should only happen for new, top-level messages, (no
|
|
|
|
* References or In-Reply-To header in this message, and no previously
|
|
|
|
* added message refers to this message).
|
2009-10-25 22:54:13 +01:00
|
|
|
*/
|
|
|
|
static notmuch_status_t
|
|
|
|
_notmuch_database_link_message (notmuch_database_t *notmuch,
|
|
|
|
notmuch_message_t *message,
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
notmuch_message_file_t *message_file,
|
|
|
|
notmuch_bool_t is_ghost)
|
2009-10-25 22:54:13 +01:00
|
|
|
{
|
2014-10-07 01:17:08 +02:00
|
|
|
void *local = talloc_new (NULL);
|
2009-10-25 23:01:20 +01:00
|
|
|
notmuch_status_t status;
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
const char *thread_id = NULL;
|
2010-04-12 23:41:34 +02:00
|
|
|
|
2014-10-07 01:17:08 +02:00
|
|
|
/* Check if the message already had a thread ID */
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
if (notmuch->features & NOTMUCH_FEATURE_GHOSTS) {
|
|
|
|
if (is_ghost)
|
|
|
|
thread_id = notmuch_message_get_thread_id (message);
|
|
|
|
} else {
|
|
|
|
thread_id = _consume_metadata_thread_id (local, notmuch, message);
|
|
|
|
if (thread_id)
|
|
|
|
_notmuch_message_add_term (message, "thread", thread_id);
|
|
|
|
}
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2009-10-25 23:01:20 +01:00
|
|
|
status = _notmuch_database_link_message_to_parents (notmuch, message,
|
|
|
|
message_file,
|
|
|
|
&thread_id);
|
|
|
|
if (status)
|
2014-10-07 01:17:08 +02:00
|
|
|
goto DONE;
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2014-10-23 14:30:41 +02:00
|
|
|
if (! (notmuch->features & NOTMUCH_FEATURE_GHOSTS)) {
|
|
|
|
/* In general, it shouldn't be necessary to link children,
|
|
|
|
* since the earlier indexing of those children will have
|
|
|
|
* stored a thread ID for the missing parent. However, prior
|
|
|
|
* to ghost messages, these stored thread IDs were NOT
|
|
|
|
* rewritten during thread merging (and there was no
|
|
|
|
* performant way to do so), so if indexed children were
|
|
|
|
* pulled into a different thread ID by a merge, it was
|
|
|
|
* necessary to pull them *back* into the stored thread ID of
|
|
|
|
* the parent. With ghost messages, we just rewrite the
|
|
|
|
* stored thread IDs during merging, so this workaround isn't
|
|
|
|
* necessary. */
|
|
|
|
status = _notmuch_database_link_message_to_children (notmuch, message,
|
|
|
|
&thread_id);
|
|
|
|
if (status)
|
|
|
|
goto DONE;
|
|
|
|
}
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2010-02-08 20:33:33 +01:00
|
|
|
/* If not part of any existing thread, generate a new thread ID. */
|
|
|
|
if (thread_id == NULL) {
|
|
|
|
thread_id = _notmuch_database_generate_thread_id (notmuch);
|
|
|
|
|
|
|
|
_notmuch_message_add_term (message, "thread", thread_id);
|
|
|
|
}
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2014-10-07 01:17:08 +02:00
|
|
|
DONE:
|
|
|
|
talloc_free (local);
|
|
|
|
|
|
|
|
return status;
|
2009-10-25 19:03:55 +01:00
|
|
|
}
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_add_message (notmuch_database_t *notmuch,
|
2009-10-27 05:44:05 +01:00
|
|
|
const char *filename,
|
|
|
|
notmuch_message_t **message_ret)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2009-10-23 14:13:42 +02:00
|
|
|
notmuch_message_file_t *message_file;
|
2009-11-09 22:43:59 +01:00
|
|
|
notmuch_message_t *message = NULL;
|
2011-06-11 06:42:58 +02:00
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS, ret2;
|
2009-10-29 00:50:14 +01:00
|
|
|
notmuch_private_status_t private_status;
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
notmuch_bool_t is_ghost = false;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-25 19:03:55 +01:00
|
|
|
const char *date, *header;
|
2009-10-29 00:50:14 +01:00
|
|
|
const char *from, *to, *subject;
|
2009-11-22 04:03:49 +01:00
|
|
|
char *message_id = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-28 00:19:20 +01:00
|
|
|
if (message_ret)
|
|
|
|
*message_ret = NULL;
|
|
|
|
|
2010-01-07 19:19:44 +01:00
|
|
|
ret = _notmuch_database_ensure_writable (notmuch);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2014-12-26 18:34:49 +01:00
|
|
|
message_file = _notmuch_message_file_open (notmuch, filename);
|
2010-01-07 19:19:44 +01:00
|
|
|
if (message_file == NULL)
|
|
|
|
return NOTMUCH_STATUS_FILE_ERROR;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2011-06-11 06:42:58 +02:00
|
|
|
/* Adding a message may change many documents. Do this all
|
|
|
|
* atomically. */
|
|
|
|
ret = notmuch_database_begin_atomic (notmuch);
|
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
|
|
|
|
2014-03-30 23:21:49 +02:00
|
|
|
/* Parse message up front to get better error status. */
|
|
|
|
ret = _notmuch_message_file_parse (message_file);
|
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
2009-10-19 22:48:13 +02:00
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
try {
|
2009-10-28 21:35:10 +01:00
|
|
|
/* Before we do any real work, (especially before doing a
|
|
|
|
* potential SHA-1 computation on the entire file's contents),
|
|
|
|
* let's make sure that what we're looking at looks like an
|
|
|
|
* actual email message.
|
|
|
|
*/
|
2014-05-13 11:44:05 +02:00
|
|
|
from = _notmuch_message_file_get_header (message_file, "from");
|
|
|
|
subject = _notmuch_message_file_get_header (message_file, "subject");
|
|
|
|
to = _notmuch_message_file_get_header (message_file, "to");
|
2009-10-28 21:35:10 +01:00
|
|
|
|
2009-11-20 21:46:37 +01:00
|
|
|
if ((from == NULL || *from == '\0') &&
|
|
|
|
(subject == NULL || *subject == '\0') &&
|
|
|
|
(to == NULL || *to == '\0'))
|
2009-10-28 21:35:10 +01:00
|
|
|
{
|
|
|
|
ret = NOTMUCH_STATUS_FILE_NOT_EMAIL;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now that we're sure it's mail, the first order of business
|
|
|
|
* is to find a message ID (or else create one ourselves). */
|
2009-10-23 15:00:10 +02:00
|
|
|
|
2014-05-13 11:44:05 +02:00
|
|
|
header = _notmuch_message_file_get_header (message_file, "message-id");
|
2009-11-20 19:31:00 +01:00
|
|
|
if (header && *header != '\0') {
|
2009-11-16 05:21:43 +01:00
|
|
|
message_id = _parse_message_id (message_file, header, NULL);
|
2009-11-22 04:03:49 +01:00
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
/* So the header value isn't RFC-compliant, but it's
|
|
|
|
* better than no message-id at all. */
|
|
|
|
if (message_id == NULL)
|
2009-10-26 23:17:10 +01:00
|
|
|
message_id = talloc_strdup (message_file, header);
|
2009-11-22 04:03:49 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (message_id == NULL ) {
|
2009-10-23 00:31:56 +02:00
|
|
|
/* No message-id at all, let's generate one by taking a
|
|
|
|
* hash over the file's contents. */
|
2014-05-13 11:44:05 +02:00
|
|
|
char *sha1 = _notmuch_sha1_of_file (filename);
|
2009-10-23 00:31:56 +02:00
|
|
|
|
|
|
|
/* If that failed too, something is really wrong. Give up. */
|
|
|
|
if (sha1 == NULL) {
|
|
|
|
ret = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
message_id = talloc_asprintf (message_file,
|
|
|
|
"notmuch-sha1-%s", sha1);
|
2009-10-23 00:31:56 +02:00
|
|
|
free (sha1);
|
2009-10-19 21:54:40 +02:00
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-23 15:00:10 +02:00
|
|
|
/* Now that we have a message ID, we get a message object,
|
|
|
|
* (which may or may not reference an existing document in the
|
|
|
|
* database). */
|
|
|
|
|
2009-11-17 18:04:14 +01:00
|
|
|
message = _notmuch_message_create_for_message_id (notmuch,
|
2009-10-25 17:47:21 +01:00
|
|
|
message_id,
|
2009-10-29 00:50:14 +01:00
|
|
|
&private_status);
|
2009-10-26 23:17:10 +01:00
|
|
|
|
|
|
|
talloc_free (message_id);
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-11-20 21:02:11 +01:00
|
|
|
if (message == NULL) {
|
|
|
|
ret = COERCE_STATUS (private_status,
|
|
|
|
"Unexpected status value from _notmuch_message_create_for_message_id");
|
2009-10-25 17:47:21 +01:00
|
|
|
goto DONE;
|
2009-11-20 21:02:11 +01:00
|
|
|
}
|
2009-10-23 14:30:37 +02:00
|
|
|
|
2009-12-21 21:08:46 +01:00
|
|
|
_notmuch_message_add_filename (message, filename);
|
|
|
|
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
/* Is this a newly created message object or a ghost
|
|
|
|
* message? We have to be slightly careful: if this is a
|
|
|
|
* blank message, it's not safe to call
|
|
|
|
* notmuch_message_get_flag yet. */
|
|
|
|
if (private_status == NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND ||
|
|
|
|
(is_ghost = notmuch_message_get_flag (
|
|
|
|
message, NOTMUCH_MESSAGE_FLAG_GHOST))) {
|
2009-10-23 15:00:10 +02:00
|
|
|
_notmuch_message_add_term (message, "type", "mail");
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
if (is_ghost)
|
|
|
|
/* Convert ghost message to a regular message */
|
|
|
|
_notmuch_message_remove_term (message, "type", "ghost");
|
2009-10-23 14:30:37 +02:00
|
|
|
|
2009-12-21 21:08:46 +01:00
|
|
|
ret = _notmuch_database_link_message (notmuch, message,
|
lib: Implement ghost-based thread linking
This updates the thread linking code to use ghost messages instead of
user metadata to link messages into threads.
In contrast with the old approach, this is actually correct.
Previously, thread merging updated only the thread IDs of message
documents, not thread IDs stored in user metadata. As originally
diagnosed by Mark Walters [1] and as demonstrated by the broken
T260-thread-order test, this can cause notmuch to fail to link
messages even though they're in the same thread. In principle the old
approach could have been fixed by updating the user metadata thread
IDs as well, but these are not indexed and hence this would have
required a full scan of all stored thread IDs. Ghost messages solve
this problem naturally by reusing the exact same thread ID and message
ID representation and indexing as regular messages.
Furthermore, thanks to this greater symmetry, ghost messages are also
algorithmically simpler. We continue to support the old user metadata
format, so this patch can't delete any code, but when we do remove
support for the old format, several functions can simply be deleted.
[1] id:8738h7kv2q.fsf@qmul.ac.uk
2014-10-23 14:30:37 +02:00
|
|
|
message_file, is_ghost);
|
2009-12-21 21:08:46 +01:00
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
2009-10-20 22:05:45 +02:00
|
|
|
|
2014-05-13 11:44:05 +02:00
|
|
|
date = _notmuch_message_file_get_header (message_file, "date");
|
2011-11-06 18:17:36 +01:00
|
|
|
_notmuch_message_set_header_values (message, date, from, subject);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2014-03-30 23:21:49 +02:00
|
|
|
ret = _notmuch_message_index_file (message, message_file);
|
2012-11-25 07:16:01 +01:00
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
2009-12-21 21:08:46 +01:00
|
|
|
} else {
|
|
|
|
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
|
|
|
|
}
|
2009-10-28 18:42:07 +01:00
|
|
|
|
|
|
|
_notmuch_message_sync (message);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "A Xapian exception occurred adding message: %s.\n",
|
2010-04-24 16:22:34 +02:00
|
|
|
error.get_msg().c_str());
|
2009-11-22 03:54:20 +01:00
|
|
|
notmuch->exception_reported = TRUE;
|
2009-10-23 00:31:56 +02:00
|
|
|
ret = NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2009-10-23 00:31:56 +02:00
|
|
|
DONE:
|
2009-10-27 05:44:05 +01:00
|
|
|
if (message) {
|
2010-10-31 22:29:15 +01:00
|
|
|
if ((ret == NOTMUCH_STATUS_SUCCESS ||
|
|
|
|
ret == NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID) && message_ret)
|
2009-10-27 05:44:05 +01:00
|
|
|
*message_ret = message;
|
|
|
|
else
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
}
|
|
|
|
|
2009-10-23 14:13:42 +02:00
|
|
|
if (message_file)
|
2014-05-13 11:44:05 +02:00
|
|
|
_notmuch_message_file_close (message_file);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2011-06-11 06:42:58 +02:00
|
|
|
ret2 = notmuch_database_end_atomic (notmuch);
|
|
|
|
if ((ret == NOTMUCH_STATUS_SUCCESS ||
|
|
|
|
ret == NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID) &&
|
|
|
|
ret2 != NOTMUCH_STATUS_SUCCESS)
|
|
|
|
ret = ret2;
|
|
|
|
|
2009-10-23 00:31:56 +02:00
|
|
|
return ret;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
2009-11-23 01:10:54 +01:00
|
|
|
|
2009-12-22 00:14:32 +01:00
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_remove_message (notmuch_database_t *notmuch,
|
|
|
|
const char *filename)
|
2011-06-11 06:19:31 +02:00
|
|
|
{
|
2011-10-04 06:55:29 +02:00
|
|
|
notmuch_status_t status;
|
|
|
|
notmuch_message_t *message;
|
2011-06-11 06:19:31 +02:00
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
status = notmuch_database_find_message_by_filename (notmuch, filename,
|
|
|
|
&message);
|
|
|
|
|
|
|
|
if (status == NOTMUCH_STATUS_SUCCESS && message) {
|
2011-06-11 06:19:31 +02:00
|
|
|
status = _notmuch_message_remove_filename (message, filename);
|
|
|
|
if (status == NOTMUCH_STATUS_SUCCESS)
|
|
|
|
_notmuch_message_delete (message);
|
|
|
|
else if (status == NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID)
|
|
|
|
_notmuch_message_sync (message);
|
2011-10-03 22:27:32 +02:00
|
|
|
|
|
|
|
notmuch_message_destroy (message);
|
2011-06-11 06:19:31 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
notmuch_status_t
|
2011-06-11 06:19:31 +02:00
|
|
|
notmuch_database_find_message_by_filename (notmuch_database_t *notmuch,
|
2011-10-04 06:55:29 +02:00
|
|
|
const char *filename,
|
|
|
|
notmuch_message_t **message_ret)
|
2009-12-22 00:14:32 +01:00
|
|
|
{
|
2010-04-24 16:22:34 +02:00
|
|
|
void *local;
|
2010-01-05 22:29:23 +01:00
|
|
|
const char *prefix = _find_prefix ("file-direntry");
|
2009-12-22 00:14:32 +01:00
|
|
|
char *direntry, *term;
|
|
|
|
Xapian::PostingIterator i, end;
|
|
|
|
notmuch_status_t status;
|
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
if (message_ret == NULL)
|
|
|
|
return NOTMUCH_STATUS_NULL_POINTER;
|
|
|
|
|
2014-08-25 19:26:08 +02:00
|
|
|
if (! (notmuch->features & NOTMUCH_FEATURE_FILE_TERMS))
|
|
|
|
return NOTMUCH_STATUS_UPGRADE_REQUIRED;
|
|
|
|
|
2012-03-17 17:41:27 +01:00
|
|
|
/* return NULL on any failure */
|
|
|
|
*message_ret = NULL;
|
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
local = talloc_new (notmuch);
|
|
|
|
|
|
|
|
try {
|
2012-05-18 06:13:36 +02:00
|
|
|
status = _notmuch_database_filename_to_direntry (
|
2012-05-18 06:13:40 +02:00
|
|
|
local, notmuch, filename, NOTMUCH_FIND_LOOKUP, &direntry);
|
|
|
|
if (status || !direntry)
|
2011-10-04 06:55:29 +02:00
|
|
|
goto DONE;
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2011-01-15 23:01:43 +01:00
|
|
|
term = talloc_asprintf (local, "%s%s", prefix, direntry);
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
find_doc_ids_for_term (notmuch, term, &i, &end);
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2011-06-11 06:19:31 +02:00
|
|
|
if (i != end) {
|
2011-01-15 23:09:04 +01:00
|
|
|
notmuch_private_status_t private_status;
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
*message_ret = _notmuch_message_create (notmuch, notmuch, *i,
|
|
|
|
&private_status);
|
|
|
|
if (*message_ret == NULL)
|
|
|
|
status = NOTMUCH_STATUS_OUT_OF_MEMORY;
|
2009-12-22 00:14:32 +01:00
|
|
|
}
|
2010-04-24 16:22:34 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (notmuch, "Error: A Xapian exception occurred finding message by filename: %s\n",
|
2010-04-24 16:22:34 +02:00
|
|
|
error.get_msg().c_str());
|
|
|
|
notmuch->exception_reported = TRUE;
|
2011-10-04 06:55:29 +02:00
|
|
|
status = NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
2009-12-22 00:14:32 +01:00
|
|
|
}
|
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
DONE:
|
2009-12-22 00:14:32 +01:00
|
|
|
talloc_free (local);
|
|
|
|
|
2011-10-04 06:55:29 +02:00
|
|
|
if (status && *message_ret) {
|
|
|
|
notmuch_message_destroy (*message_ret);
|
|
|
|
*message_ret = NULL;
|
|
|
|
}
|
|
|
|
return status;
|
2009-12-22 00:14:32 +01:00
|
|
|
}
|
|
|
|
|
2010-12-09 06:32:35 +01:00
|
|
|
notmuch_string_list_t *
|
|
|
|
_notmuch_database_get_terms_with_prefix (void *ctx, Xapian::TermIterator &i,
|
|
|
|
Xapian::TermIterator &end,
|
|
|
|
const char *prefix)
|
2009-11-23 01:10:54 +01:00
|
|
|
{
|
2010-12-09 06:32:35 +01:00
|
|
|
int prefix_len = strlen (prefix);
|
2010-12-09 01:26:05 +01:00
|
|
|
notmuch_string_list_t *list;
|
2009-11-23 01:10:54 +01:00
|
|
|
|
2010-12-09 01:26:05 +01:00
|
|
|
list = _notmuch_string_list_create (ctx);
|
|
|
|
if (unlikely (list == NULL))
|
2009-11-23 01:10:54 +01:00
|
|
|
return NULL;
|
|
|
|
|
2010-12-09 06:32:35 +01:00
|
|
|
for (i.skip_to (prefix); i != end; i++) {
|
|
|
|
/* Terminate loop at first term without desired prefix. */
|
|
|
|
if (strncmp ((*i).c_str (), prefix, prefix_len))
|
2009-11-23 01:10:54 +01:00
|
|
|
break;
|
|
|
|
|
2010-12-09 06:32:35 +01:00
|
|
|
_notmuch_string_list_append (list, (*i).c_str () + prefix_len);
|
2009-11-23 01:10:54 +01:00
|
|
|
}
|
|
|
|
|
2010-12-09 06:32:35 +01:00
|
|
|
return list;
|
2009-11-23 01:10:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_tags_t *
|
|
|
|
notmuch_database_get_all_tags (notmuch_database_t *db)
|
|
|
|
{
|
|
|
|
Xapian::TermIterator i, end;
|
2010-12-09 06:32:35 +01:00
|
|
|
notmuch_string_list_t *tags;
|
2010-04-24 16:22:34 +02:00
|
|
|
|
|
|
|
try {
|
|
|
|
i = db->xapian_db->allterms_begin();
|
|
|
|
end = db->xapian_db->allterms_end();
|
2010-12-09 06:32:35 +01:00
|
|
|
tags = _notmuch_database_get_terms_with_prefix (db, i, end,
|
|
|
|
_find_prefix ("tag"));
|
|
|
|
_notmuch_string_list_sort (tags);
|
|
|
|
return _notmuch_tags_create (db, tags);
|
2010-04-24 16:22:34 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
2014-12-26 17:25:35 +01:00
|
|
|
_notmuch_database_log (db, "A Xapian exception occurred getting tags: %s.\n",
|
2010-04-24 16:22:34 +02:00
|
|
|
error.get_msg().c_str());
|
|
|
|
db->exception_reported = TRUE;
|
|
|
|
return NULL;
|
|
|
|
}
|
2009-11-23 01:10:54 +01:00
|
|
|
}
|
2014-12-26 09:01:01 +01:00
|
|
|
|
|
|
|
const char *
|
2015-06-07 17:02:00 +02:00
|
|
|
notmuch_database_status_string (const notmuch_database_t *notmuch)
|
2014-12-26 09:01:01 +01:00
|
|
|
{
|
|
|
|
return notmuch->status_string;
|
|
|
|
}
|