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"
|
2017-12-26 02:03:05 +01:00
|
|
|
#include "thread-fp.h"
|
2017-02-27 03:34:20 +01:00
|
|
|
#include "regexp-fields.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
|
|
|
|
2019-06-13 12:55:35 +02:00
|
|
|
#include <glib.h> /* g_free, GPtrArray, GHashTable */
|
|
|
|
#include <glib-object.h> /* g_type_init */
|
2009-10-19 21:54:40 +02:00
|
|
|
|
2019-06-13 12:55:35 +02:00
|
|
|
#include <gmime/gmime.h> /* g_mime_init */
|
2011-12-31 05:37:41 +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
|
|
|
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
|
|
|
|
2019-06-13 12:55:35 +02:00
|
|
|
#define STRINGIFY(s) _SUB_STRINGIFY (s)
|
2010-01-08 03:26:31 +01:00
|
|
|
#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
|
|
|
|
|
2020-07-15 00:31:10 +02:00
|
|
|
#define LOG_XAPIAN_EXCEPTION(message, error) _log_xapian_exception (__location__, message, error)
|
|
|
|
|
|
|
|
static void
|
|
|
|
_log_xapian_exception (const char *where, notmuch_database_t *notmuch, const Xapian::Error error) {
|
|
|
|
_notmuch_database_log (notmuch,
|
|
|
|
"A Xapian exception occurred at %s: %s\n",
|
|
|
|
where,
|
|
|
|
error.get_msg ().c_str ());
|
|
|
|
notmuch->exception_reported = true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
*
|
2019-03-13 01:47:10 +01:00
|
|
|
* There are two kinds of prefixes used in notmuch. There are the
|
|
|
|
* human friendly 'prefix names' like "thread:", which are also used
|
|
|
|
* in the query parser, and the actual prefix terms in the database
|
|
|
|
* (e.g. "G"). The correspondence is maintained in the file scope data
|
|
|
|
* structure 'prefix_table'.
|
|
|
|
*
|
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
|
2019-03-13 01:47:09 +01:00
|
|
|
* is stored in one or more files on disk 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.
|
|
|
|
*
|
2019-03-19 01:39:21 +01:00
|
|
|
* The prefixed terms described above are also searchable without an
|
|
|
|
* explicit field name, but as of notmuch 0.29 this is due to
|
|
|
|
* query-parser setup, not extra terms in the database. In addition,
|
|
|
|
* terms from the content of the message are added without a prefix
|
|
|
|
* for use by the user in searching. Note that the prefix name "body"
|
|
|
|
* is used to refer to the empty prefix string in the database.
|
2019-03-13 01:47:11 +01:00
|
|
|
*
|
|
|
|
* The path of the containing folder is added with the "folder" prefix
|
|
|
|
* (see _notmuch_message_add_folder_terms). Sub-paths of the the path
|
|
|
|
* of the mail message are added with the "path" prefix.
|
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 */
|
2019-06-13 12:55:35 +02:00
|
|
|
{ "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 },
|
|
|
|
{ "body", "", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROBABILISTIC },
|
|
|
|
{ "thread", "G", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "tag", "K", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "is", "K", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "id", "Q", NOTMUCH_FIELD_EXTERNAL },
|
|
|
|
{ "mid", "Q", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "path", "P", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "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
|
|
|
*/
|
2019-06-13 12:55:35 +02:00
|
|
|
{ "folder", "XFOLDER:", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "date", NULL, NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "query", NULL, NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "from", "XFROM", NOTMUCH_FIELD_EXTERNAL |
|
|
|
|
NOTMUCH_FIELD_PROBABILISTIC |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
|
|
|
{ "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 |
|
|
|
|
NOTMUCH_FIELD_PROCESSOR },
|
2009-10-28 18:42:07 +01:00
|
|
|
};
|
|
|
|
|
2017-02-27 03:34:19 +01:00
|
|
|
static void
|
|
|
|
_setup_query_field_default (const prefix_t *prefix, notmuch_database_t *notmuch)
|
|
|
|
{
|
2019-03-19 01:39:21 +01:00
|
|
|
if (prefix->prefix)
|
2019-06-13 12:55:35 +02:00
|
|
|
notmuch->query_parser->add_prefix ("", prefix->prefix);
|
2017-02-27 03:34:19 +01:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2019-02-26 03:10:29 +01:00
|
|
|
notmuch_string_map_iterator_t *
|
|
|
|
_notmuch_database_user_headers (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
return _notmuch_string_map_iterator_create (notmuch->user_header, "", false);
|
|
|
|
}
|
|
|
|
|
2018-11-17 15:08:59 +01:00
|
|
|
const char *
|
2019-06-13 12:55:35 +02:00
|
|
|
_user_prefix (void *ctx, const char *name)
|
2018-11-17 15:08:59 +01:00
|
|
|
{
|
2019-06-13 12:55:35 +02:00
|
|
|
return talloc_asprintf (ctx, "XU%s:", name);
|
2018-11-17 15:08:59 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static notmuch_status_t
|
|
|
|
_setup_user_query_fields (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
notmuch_config_list_t *list;
|
|
|
|
notmuch_status_t status;
|
|
|
|
|
2018-11-17 15:09:00 +01:00
|
|
|
notmuch->user_prefix = _notmuch_string_map_create (notmuch);
|
|
|
|
if (notmuch->user_prefix == NULL)
|
|
|
|
return NOTMUCH_STATUS_OUT_OF_MEMORY;
|
|
|
|
|
|
|
|
notmuch->user_header = _notmuch_string_map_create (notmuch);
|
|
|
|
if (notmuch->user_header == NULL)
|
|
|
|
return NOTMUCH_STATUS_OUT_OF_MEMORY;
|
|
|
|
|
2018-11-17 15:08:59 +01:00
|
|
|
status = notmuch_database_get_config_list (notmuch, CONFIG_HEADER_PREFIX, &list);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
for (; notmuch_config_list_valid (list); notmuch_config_list_move_to_next (list)) {
|
|
|
|
|
|
|
|
prefix_t query_field;
|
|
|
|
|
|
|
|
const char *key = notmuch_config_list_key (list)
|
2019-06-13 12:55:35 +02:00
|
|
|
+ sizeof (CONFIG_HEADER_PREFIX) - 1;
|
2018-11-17 15:08:59 +01:00
|
|
|
|
2018-11-17 15:09:00 +01:00
|
|
|
_notmuch_string_map_append (notmuch->user_prefix,
|
|
|
|
key,
|
|
|
|
_user_prefix (notmuch, key));
|
|
|
|
|
|
|
|
_notmuch_string_map_append (notmuch->user_header,
|
|
|
|
key,
|
|
|
|
notmuch_config_list_value (list));
|
|
|
|
|
2018-11-17 15:08:59 +01:00
|
|
|
query_field.name = talloc_strdup (notmuch, key);
|
|
|
|
query_field.prefix = _user_prefix (notmuch, key);
|
|
|
|
query_field.flags = NOTMUCH_FIELD_PROBABILISTIC
|
2019-06-13 12:55:35 +02:00
|
|
|
| NOTMUCH_FIELD_EXTERNAL;
|
2018-11-17 15:08:59 +01:00
|
|
|
|
|
|
|
_setup_query_field_default (&query_field, notmuch);
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_config_list_destroy (list);
|
|
|
|
|
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2017-02-27 03:34:19 +01:00
|
|
|
static void
|
|
|
|
_setup_query_field (const prefix_t *prefix, notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
if (prefix->flags & NOTMUCH_FIELD_PROCESSOR) {
|
|
|
|
Xapian::FieldProcessor *fp;
|
|
|
|
|
|
|
|
if (STRNCMP_LITERAL (prefix->name, "date") == 0)
|
2020-07-07 12:56:46 +02:00
|
|
|
fp = (new DateFieldProcessor(NOTMUCH_VALUE_TIMESTAMP))->release ();
|
|
|
|
else if (STRNCMP_LITERAL(prefix->name, "query") == 0)
|
2017-02-27 03:34:19 +01:00
|
|
|
fp = (new QueryFieldProcessor (*notmuch->query_parser, notmuch))->release ();
|
2019-06-13 12:55:35 +02:00
|
|
|
else if (STRNCMP_LITERAL (prefix->name, "thread") == 0)
|
2017-12-26 02:03:05 +01:00
|
|
|
fp = (new ThreadFieldProcessor (*notmuch->query_parser, notmuch))->release ();
|
2017-02-27 03:34:19 +01:00
|
|
|
else
|
2017-02-15 13:58:28 +01:00
|
|
|
fp = (new RegexpFieldProcessor (prefix->name, prefix->flags,
|
|
|
|
*notmuch->query_parser, notmuch))->release ();
|
2017-02-27 03:34:19 +01:00
|
|
|
|
|
|
|
/* we treat all field-processor fields as boolean in order to get the raw input */
|
2019-03-19 01:39:21 +01:00
|
|
|
if (prefix->prefix)
|
2019-06-13 12:55:35 +02:00
|
|
|
notmuch->query_parser->add_prefix ("", prefix->prefix);
|
2017-02-27 03:34:19 +01:00
|
|
|
notmuch->query_parser->add_boolean_prefix (prefix->name, fp);
|
|
|
|
} else {
|
|
|
|
_setup_query_field_default (prefix, notmuch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 "";
|
|
|
|
}
|
|
|
|
|
2019-02-26 02:57:40 +01:00
|
|
|
/* Like find prefix, but include the possibility of user defined
|
|
|
|
* prefixes specific to this database */
|
|
|
|
|
|
|
|
const char *
|
|
|
|
_notmuch_database_prefix (notmuch_database_t *notmuch, const char *name)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
/*XXX TODO: reduce code duplication */
|
|
|
|
for (i = 0; i < ARRAY_SIZE (prefix_table); i++) {
|
|
|
|
if (strcmp (name, prefix_table[i].name) == 0)
|
|
|
|
return prefix_table[i].prefix;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (notmuch->user_prefix)
|
|
|
|
return _notmuch_string_map_get (notmuch->user_prefix, name);
|
|
|
|
|
|
|
|
return 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
|
|
|
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,
|
2019-06-13 12:55:35 +02:00
|
|
|
"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,
|
2019-06-13 12:55:35 +02:00
|
|
|
"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,
|
2019-06-13 12:55:35 +02:00
|
|
|
"modification tracking", "w" },
|
2019-03-19 01:39:21 +01:00
|
|
|
/* Existing databases will work fine for all queries not involving
|
|
|
|
* 'body:' */
|
|
|
|
{ NOTMUCH_FEATURE_UNPREFIX_BODY_ONLY,
|
2019-06-13 12:55:35 +02:00
|
|
|
"index body and headers separately", "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";
|
2017-10-17 21:09:56 +02:00
|
|
|
case NOTMUCH_STATUS_MALFORMED_CRYPTO_PROTOCOL:
|
|
|
|
return "Crypto protocol missing, malformed, or unintelligible";
|
|
|
|
case NOTMUCH_STATUS_FAILED_CRYPTO_CONTEXT_CREATION:
|
|
|
|
return "Crypto engine initialization failure";
|
|
|
|
case NOTMUCH_STATUS_UNKNOWN_CRYPTO_PROTOCOL:
|
|
|
|
return "Unknown crypto protocol";
|
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,
|
2019-06-13 12:55:35 +02:00
|
|
|
const char *format,
|
|
|
|
...)
|
2014-12-26 09:01:01 +01:00
|
|
|
{
|
|
|
|
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,
|
2019-06-13 12:55:35 +02:00
|
|
|
const char *format,
|
|
|
|
...)
|
2016-07-15 12:25:41 +02:00
|
|
|
{
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2017-06-04 14:32:24 +02:00
|
|
|
void
|
|
|
|
_notmuch_database_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;
|
|
|
|
|
2017-06-04 14:32:24 +02:00
|
|
|
_notmuch_database_find_doc_ids (notmuch, prefix_name, value, &i, &end);
|
2009-10-23 23:24:07 +02:00
|
|
|
|
|
|
|
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",
|
2019-06-13 12:55:35 +02:00
|
|
|
error.get_msg ().c_str ());
|
2017-10-07 10:44:05 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
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",
|
2019-06-13 12:55:35 +02:00
|
|
|
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;
|
2019-03-19 01:39:21 +01:00
|
|
|
notmuch->features |= NOTMUCH_FEATURE_UNPREFIX_BODY_ONLY;
|
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) {
|
2019-06-13 12:55:35 +02:00
|
|
|
notmuch_database_close (notmuch);
|
2012-04-30 18:25:34 +02:00
|
|
|
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)
|
2017-10-07 10:44:05 +02:00
|
|
|
notmuch->atomic_dirty = true;
|
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
|
|
|
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,
|
2019-06-13 12:55:35 +02:00
|
|
|
&status_string);
|
2014-12-27 19:12:49 +01:00
|
|
|
|
|
|
|
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 */
|
2019-06-13 12:55:35 +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) {
|
2019-05-02 15:19:42 +02:00
|
|
|
g_mime_init ();
|
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);
|
2017-10-07 10:44:05 +02: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
|
|
|
|
2019-06-13 12:55:35 +02:00
|
|
|
strip_trailing (notmuch->path, '/');
|
2009-10-29 00:50:14 +01:00
|
|
|
|
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,
|
2019-06-13 12:55:35 +02:00
|
|
|
"Error: Notmuch database at %s\n"
|
|
|
|
" has a newer database format version (%u) than supported by this\n"
|
|
|
|
" version of notmuch (%u).\n",
|
2014-12-27 19:12:49 +01:00
|
|
|
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,
|
2019-06-13 12:55:35 +02:00
|
|
|
"Error: Notmuch database at %s\n"
|
|
|
|
" requires features (%s)\n"
|
|
|
|
" not supported by this version of notmuch.\n",
|
2014-12-27 19:12:49 +01:00
|
|
|
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"));
|
2020-07-07 12:56:46 +02:00
|
|
|
notmuch->value_range_processor = new Xapian::NumberRangeProcessor (NOTMUCH_VALUE_TIMESTAMP);
|
|
|
|
notmuch->date_range_processor = new ParseTimeRangeProcessor (NOTMUCH_VALUE_TIMESTAMP, "date:");
|
|
|
|
notmuch->last_mod_range_processor = new Xapian::NumberRangeProcessor (NOTMUCH_VALUE_LAST_MOD, "lastmod:");
|
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);
|
2020-07-07 12:56:46 +02:00
|
|
|
notmuch->query_parser->add_rangeprocessor (notmuch->value_range_processor);
|
|
|
|
notmuch->query_parser->add_rangeprocessor (notmuch->date_range_processor);
|
|
|
|
notmuch->query_parser->add_rangeprocessor (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) {
|
2017-02-27 03:34:19 +01:00
|
|
|
_setup_query_field (prefix, notmuch);
|
2017-02-17 04:07:49 +01:00
|
|
|
}
|
2009-10-28 18:42:07 +01:00
|
|
|
}
|
2018-11-17 15:08:59 +01:00
|
|
|
status = _setup_user_query_fields (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
|
|
|
} 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",
|
2019-06-13 12:55:35 +02:00
|
|
|
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);
|
2020-07-14 13:25:28 +02:00
|
|
|
|
|
|
|
if (notmuch)
|
|
|
|
notmuch->open = true;
|
|
|
|
|
2012-04-30 18:25:33 +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
|
|
|
}
|
|
|
|
|
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. */
|
2020-07-14 13:25:28 +02:00
|
|
|
if (notmuch->open) {
|
2012-03-02 15:58:39 +01:00
|
|
|
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))
|
2019-06-13 12:55:35 +02:00
|
|
|
->cancel_transaction ();
|
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
|
|
|
|
|
|
|
/* Close the database. This implicitly flushes
|
|
|
|
* outstanding changes. */
|
2019-06-13 12:55:35 +02:00
|
|
|
notmuch->xapian_db->close ();
|
2012-03-02 15:58:39 +01:00
|
|
|
} 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",
|
2019-06-13 12:55:35 +02:00
|
|
|
error.get_msg ().c_str ());
|
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
|
|
|
}
|
2012-03-02 15:58:39 +01:00
|
|
|
}
|
|
|
|
}
|
2020-07-14 13:25:28 +02:00
|
|
|
notmuch->open = false;
|
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 ());
|
2017-10-07 10:44:05 +02:00
|
|
|
notmuch->exception_reported = true;
|
2017-02-24 02:38:24 +01:00
|
|
|
}
|
|
|
|
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) :
|
2019-06-13 12:55:35 +02: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)
|
2019-06-13 12:55:35 +02:00
|
|
|
msg = talloc_asprintf (NULL, "compacting table %s", table.c_str ());
|
2013-10-02 22:30:46 +02:00
|
|
|
else
|
2019-06-13 12:55:35 +02:00
|
|
|
msg = talloc_asprintf (NULL, " %s", status.c_str ());
|
2013-10-02 22:30:46 +02:00
|
|
|
|
|
|
|
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;
|
2017-10-07 10:44:05 +02:00
|
|
|
bool 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;
|
|
|
|
}
|
2017-10-07 10:44:05 +02:00
|
|
|
keep_backup = false;
|
2019-06-13 12:55:35 +02:00
|
|
|
} else {
|
2017-10-07 10:44:05 +02:00
|
|
|
keep_backup = true;
|
2013-11-14 23:03:25 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
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",
|
2019-06-13 12:55:35 +02:00
|
|
|
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-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);
|
2020-07-07 12:56:45 +02:00
|
|
|
notmuch->xapian_db->compact (compact_xapian_path, Xapian::DBCOMPACT_NO_RENUMBER, 0, compactor);
|
2013-11-13 18:02:44 +01:00
|
|
|
} catch (const Xapian::Error &error) {
|
2019-06-13 12:55:35 +02: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",
|
2019-06-13 12:55:35 +02: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",
|
2019-06-13 12:55:35 +02: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",
|
2019-06-13 12:55:35 +02:00
|
|
|
backup_path, strerror (errno));
|
2013-11-14 23:03:27 +01:00
|
|
|
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);
|
2020-07-14 13:25:28 +02:00
|
|
|
|
|
|
|
delete notmuch->term_gen;
|
|
|
|
notmuch->term_gen = NULL;
|
|
|
|
delete notmuch->query_parser;
|
|
|
|
notmuch->query_parser = NULL;
|
|
|
|
delete notmuch->xapian_db;
|
|
|
|
notmuch->xapian_db = NULL;
|
|
|
|
delete notmuch->value_range_processor;
|
|
|
|
notmuch->value_range_processor = NULL;
|
|
|
|
delete notmuch->date_range_processor;
|
|
|
|
notmuch->date_range_processor = NULL;
|
|
|
|
delete notmuch->last_mod_range_processor;
|
|
|
|
notmuch->last_mod_range_processor = NULL;
|
|
|
|
|
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;
|
|
|
|
|
2020-07-15 00:31:10 +02:00
|
|
|
try {
|
|
|
|
version_string = notmuch->xapian_db->get_metadata ("version");
|
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
LOG_XAPIAN_EXCEPTION (notmuch, error);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
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)
|
|
|
|
{
|
2020-07-17 00:28:22 +02:00
|
|
|
unsigned int version;
|
|
|
|
|
|
|
|
if (notmuch->mode != NOTMUCH_DATABASE_MODE_READ_WRITE)
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
if (NOTMUCH_FEATURES_CURRENT & ~notmuch->features)
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
version = notmuch_database_get_version (notmuch);
|
|
|
|
|
|
|
|
return (version > 0 && version < 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,
|
2020-07-07 12:56:46 +02:00
|
|
|
void (*progress_notify) (void *closure,
|
|
|
|
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;
|
2017-10-07 10:44:05 +02:00
|
|
|
bool 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);
|
|
|
|
|
2017-10-07 10:44:05 +02:00
|
|
|
timer_is_active = true;
|
2010-01-08 03:26:31 +01:00
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2017-02-26 22:21:34 +01:00
|
|
|
status = notmuch_query_count_messages (query, &msg_count);
|
2015-09-27 17:31:57 +02:00
|
|
|
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, "");
|
|
|
|
|
2017-02-26 22:21:32 +01:00
|
|
|
status = notmuch_query_search_messages (query, &messages);
|
2015-09-27 17:32:01 +02:00
|
|
|
if (status)
|
|
|
|
goto DONE;
|
|
|
|
for (;
|
2010-03-09 18:22:29 +01:00
|
|
|
notmuch_messages_valid (messages);
|
2019-06-13 12:55:35 +02:00
|
|
|
notmuch_messages_move_to_next (messages)) {
|
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;
|
2019-06-13 12:55:35 +02:00
|
|
|
t++) {
|
2010-01-08 03:26:31 +01:00
|
|
|
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;
|
2019-06-13 12:55:35 +02:00
|
|
|
p++) {
|
2010-01-08 03:26:31 +01:00
|
|
|
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));
|
|
|
|
|
2020-07-19 12:36:47 +02:00
|
|
|
directory = _notmuch_directory_find_or_create (notmuch, term.c_str () + 10,
|
|
|
|
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,
|
2019-06-13 12:55:35 +02:00
|
|
|
"Upgrade failed while creating ghost messages.\n");
|
2014-10-23 14:30:38 +02:00
|
|
|
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
|
|
|
|
2019-06-13 12:55:35 +02:00
|
|
|
DONE:
|
2014-10-23 14:30:38 +02:00
|
|
|
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",
|
2019-06-13 12:55:35 +02:00
|
|
|
error.get_msg ().c_str ());
|
2017-10-07 10:44:05 +02:00
|
|
|
notmuch->exception_reported = true;
|
2011-01-29 17:25:24 +01:00
|
|
|
return NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
}
|
2011-06-11 05:35:06 +02:00
|
|
|
|
2019-06-13 12:55:35 +02:00
|
|
|
DONE:
|
2011-06-11 05:35:06 +02:00
|
|
|
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",
|
2019-06-13 12:55:35 +02:00
|
|
|
error.get_msg ().c_str ());
|
2017-10-07 10:44:05 +02:00
|
|
|
notmuch->exception_reported = true;
|
2011-01-29 17:25:24 +01:00
|
|
|
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;
|
2017-10-07 10:44:05 +02:00
|
|
|
notmuch->atomic_dirty = false;
|
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
|
|
|
}
|
|
|
|
|
2019-06-13 12:55:35 +02:00
|
|
|
DONE:
|
2011-06-11 05:35:06 +02:00
|
|
|
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,
|
2019-06-13 12:55:35 +02:00
|
|
|
const char **uuid)
|
2014-10-13 08:20:02 +02:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2020-07-19 12:36:47 +02:00
|
|
|
directory = _notmuch_directory_find_or_create (notmuch, path, flags, &status);
|
2019-06-13 12:55:35 +02:00
|
|
|
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);
|
2019-06-13 12:55:35 +02:00
|
|
|
if (status || directory_id == (unsigned int) -1) {
|
2012-05-18 06:13:36 +02:00
|
|
|
*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 == '/') {
|
2019-06-13 12:55:35 +02:00
|
|
|
while (*relative == '/' && *(relative + 1) == '/')
|
2009-12-19 21:32:11 +01:00
|
|
|
relative++;
|
|
|
|
|
2019-06-13 12:55:35 +02:00
|
|
|
if (strncmp (relative, db_path, db_path_len) == 0) {
|
2009-12-19 21:32:11 +01:00
|
|
|
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 {
|
2020-07-19 12:36:47 +02:00
|
|
|
*directory = _notmuch_directory_find_or_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",
|
2019-06-13 12:55:35 +02:00
|
|
|
error.get_msg ().c_str ());
|
2017-10-07 10:44:05 +02:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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) {
|
2019-06-13 12:55:35 +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
|
|
|
|
2019-06-13 12:55:35 +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);
|
2019-06-13 12:55:35 +02:00
|
|
|
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",
|
2019-06-13 12:55:35 +02:00
|
|
|
error.get_msg ().c_str ());
|
2017-10-07 10:44:05 +02:00
|
|
|
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 {
|
2019-06-13 12:55:35 +02:00
|
|
|
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",
|
2019-06-13 12:55:35 +02:00
|
|
|
error.get_msg ().c_str ());
|
2017-10-07 10:44:05 +02:00
|
|
|
db->exception_reported = true;
|
2010-04-24 16:22:34 +02:00
|
|
|
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;
|
|
|
|
}
|