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
|
|
|
|
* along with this program. If not, see http://www.gnu.org/licenses/ .
|
|
|
|
*
|
|
|
|
* Author: Carl Worth <cworth@cworth.org>
|
|
|
|
*/
|
|
|
|
|
2009-10-21 06:03:30 +02:00
|
|
|
#include "database-private.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>
|
|
|
|
#include <signal.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 <xapian.h>
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
#include <glib.h> /* g_free, GPtrArray, GHashTable */
|
2009-10-19 21:54:40 +02:00
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
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;
|
|
|
|
} prefix_t;
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
#define NOTMUCH_DATABASE_VERSION 1
|
|
|
|
|
|
|
|
#define STRINGIFY(s) _SUB_STRINGIFY(s)
|
|
|
|
#define _SUB_STRINGIFY(s) #s
|
|
|
|
|
|
|
|
/* Here's the current schema for our database (for NOTMUCH_DATABASE_VERSION):
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
2010-04-13 00:15:14 +02:00
|
|
|
* We currently have two different types of documents (mail and
|
|
|
|
* directory) and also some metadata.
|
2009-10-25 16:57:09 +01:00
|
|
|
*
|
|
|
|
* Mail document
|
|
|
|
* -------------
|
|
|
|
* A mail document is associated with a particular email message file
|
2009-11-18 03:48:38 +01:00
|
|
|
* on disk. 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:
|
|
|
|
*
|
2009-11-18 03:44:02 +01:00
|
|
|
* reference: All message IDs from In-Reply-To and Re ferences
|
|
|
|
* 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
|
|
|
*
|
2009-10-25 16:57:09 +01:00
|
|
|
* A mail document also has two values:
|
|
|
|
*
|
|
|
|
* TIMESTAMP: The time_t value corresponding to the message's
|
|
|
|
* Date header.
|
|
|
|
*
|
|
|
|
* MESSAGE_ID: The unique ID of the mail mess (see "id" above)
|
|
|
|
*
|
2009-11-18 03:48:38 +01:00
|
|
|
* In addition, terms from the content of the message are added with
|
|
|
|
* "from", "to", "attachment", and "subject" prefixes for use by the
|
|
|
|
* user in searching. But the database doesn't really care itself
|
|
|
|
* about any of these.
|
|
|
|
*
|
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
|
|
|
*
|
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
|
|
|
|
* all). Succesive versions are allocated as
|
|
|
|
* changes are made to the database (such as by
|
|
|
|
* indexing new fields).
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* thread_id_* A pre-allocated thread ID for a particular
|
|
|
|
* message. This is actually an arbitarily 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:
|
|
|
|
*
|
|
|
|
* http://xapian.org/docs/omega/termprefixes.html
|
|
|
|
*
|
|
|
|
* 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).
|
|
|
|
*/
|
|
|
|
|
2009-10-25 06:38:43 +01:00
|
|
|
prefix_t BOOLEAN_PREFIX_INTERNAL[] = {
|
2010-01-05 22:29:23 +01:00
|
|
|
{ "type", "T" },
|
|
|
|
{ "reference", "XREFERENCE" },
|
|
|
|
{ "replyto", "XREPLYTO" },
|
|
|
|
{ "directory", "XDIRECTORY" },
|
|
|
|
{ "file-direntry", "XFDIRENTRY" },
|
|
|
|
{ "directory-direntry", "XDDIRENTRY" },
|
2009-10-25 05:52:48 +01:00
|
|
|
};
|
|
|
|
|
2009-10-25 06:38:43 +01:00
|
|
|
prefix_t BOOLEAN_PREFIX_EXTERNAL[] = {
|
2010-01-05 22:29:23 +01:00
|
|
|
{ "thread", "G" },
|
|
|
|
{ "tag", "K" },
|
2010-03-10 01:03:58 +01:00
|
|
|
{ "is", "K" },
|
2010-01-05 22:29:23 +01:00
|
|
|
{ "id", "Q" }
|
2009-10-25 06:38:43 +01:00
|
|
|
};
|
|
|
|
|
2009-10-28 18:42:07 +01:00
|
|
|
prefix_t PROBABILISTIC_PREFIX[]= {
|
2010-01-05 22:29:23 +01:00
|
|
|
{ "from", "XFROM" },
|
|
|
|
{ "to", "XTO" },
|
|
|
|
{ "attachment", "XATTACHMENT" },
|
|
|
|
{ "subject", "XSUBJECT"}
|
2009-10-28 18:42:07 +01:00
|
|
|
};
|
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
int
|
|
|
|
_internal_error (const char *format, ...)
|
|
|
|
{
|
|
|
|
va_list va_args;
|
|
|
|
|
|
|
|
va_start (va_args, format);
|
|
|
|
|
2009-10-28 20:46:50 +01:00
|
|
|
fprintf (stderr, "Internal error: ");
|
2009-10-25 22:54:13 +01:00
|
|
|
vfprintf (stderr, format, va_args);
|
|
|
|
|
|
|
|
exit (1);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-10-25 05:52:48 +01:00
|
|
|
const char *
|
|
|
|
_find_prefix (const char *name)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
2009-11-22 00:14:39 +01:00
|
|
|
for (i = 0; i < ARRAY_SIZE (BOOLEAN_PREFIX_INTERNAL); i++) {
|
2009-10-25 06:38:43 +01:00
|
|
|
if (strcmp (name, BOOLEAN_PREFIX_INTERNAL[i].name) == 0)
|
|
|
|
return BOOLEAN_PREFIX_INTERNAL[i].prefix;
|
2009-11-22 00:14:39 +01:00
|
|
|
}
|
2009-10-25 06:38:43 +01:00
|
|
|
|
2009-11-22 00:14:39 +01:00
|
|
|
for (i = 0; i < ARRAY_SIZE (BOOLEAN_PREFIX_EXTERNAL); i++) {
|
2009-10-25 06:38:43 +01:00
|
|
|
if (strcmp (name, BOOLEAN_PREFIX_EXTERNAL[i].name) == 0)
|
|
|
|
return BOOLEAN_PREFIX_EXTERNAL[i].prefix;
|
2009-11-22 00:14:39 +01:00
|
|
|
}
|
2009-10-25 05:52:48 +01:00
|
|
|
|
2009-11-22 00:14:39 +01:00
|
|
|
for (i = 0; i < ARRAY_SIZE (PROBABILISTIC_PREFIX); i++) {
|
2009-10-28 18:42:07 +01:00
|
|
|
if (strcmp (name, PROBABILISTIC_PREFIX[i].name) == 0)
|
|
|
|
return PROBABILISTIC_PREFIX[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 "";
|
|
|
|
}
|
|
|
|
|
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";
|
2009-10-22 01:12:53 +02:00
|
|
|
default:
|
|
|
|
case NOTMUCH_STATUS_LAST_STATUS:
|
|
|
|
return "Unknown error status value";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-12-22 00:12:52 +01:00
|
|
|
static void
|
|
|
|
find_doc_ids_for_term (notmuch_database_t *notmuch,
|
|
|
|
const char *term,
|
|
|
|
Xapian::PostingIterator *begin,
|
|
|
|
Xapian::PostingIterator *end)
|
|
|
|
{
|
|
|
|
*begin = notmuch->xapian_db->postlist_begin (term);
|
|
|
|
|
|
|
|
*end = notmuch->xapian_db->postlist_end (term);
|
|
|
|
}
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
static void
|
2009-10-23 23:06:24 +02:00
|
|
|
find_doc_ids (notmuch_database_t *notmuch,
|
|
|
|
const char *prefix_name,
|
|
|
|
const char *value,
|
|
|
|
Xapian::PostingIterator *begin,
|
|
|
|
Xapian::PostingIterator *end)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
|
|
|
char *term;
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
term = talloc_asprintf (notmuch, "%s%s",
|
|
|
|
_find_prefix (prefix_name), value);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-12-22 00:12:52 +01:00
|
|
|
find_doc_ids_for_term (notmuch, term, begin, end);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
talloc_free (term);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2010-01-05 22:29:23 +01:00
|
|
|
notmuch_private_status_t
|
|
|
|
_notmuch_database_find_unique_doc_id (notmuch_database_t *notmuch,
|
|
|
|
const char *prefix_name,
|
|
|
|
const char *value,
|
|
|
|
unsigned int *doc_id)
|
2009-10-23 23:24:07 +02:00
|
|
|
{
|
|
|
|
Xapian::PostingIterator i, end;
|
|
|
|
|
|
|
|
find_doc_ids (notmuch, prefix_name, value, &i, &end);
|
|
|
|
|
|
|
|
if (i == end) {
|
|
|
|
*doc_id = 0;
|
|
|
|
return NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND;
|
|
|
|
}
|
2009-12-22 00:11:32 +01:00
|
|
|
|
|
|
|
*doc_id = *i;
|
|
|
|
|
|
|
|
#if DEBUG_DATABASE_SANITY
|
|
|
|
i++;
|
|
|
|
|
|
|
|
if (i != end)
|
|
|
|
INTERNAL_ERROR ("Term %s:%s is not unique as expected.\n",
|
|
|
|
prefix_name, value);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return NOTMUCH_PRIVATE_STATUS_SUCCESS;
|
2009-10-23 23:24:07 +02:00
|
|
|
}
|
|
|
|
|
2009-10-23 23:12:06 +02:00
|
|
|
static Xapian::Document
|
|
|
|
find_document_for_doc_id (notmuch_database_t *notmuch, unsigned doc_id)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2009-10-23 23:12:06 +02:00
|
|
|
return notmuch->xapian_db->get_document (doc_id);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2010-06-04 21:39:36 +02:00
|
|
|
/* Generate a compressed version of 'message_id' of the form:
|
|
|
|
*
|
|
|
|
* notmuch-sha1-<sha1_sum_of_message_id>
|
|
|
|
*/
|
|
|
|
static char *
|
|
|
|
_message_id_compressed (void *ctx, const char *message_id)
|
|
|
|
{
|
|
|
|
char *sha1, *compressed;
|
|
|
|
|
|
|
|
sha1 = notmuch_sha1_of_string (message_id);
|
|
|
|
|
|
|
|
compressed = talloc_asprintf (ctx, "notmuch-sha1-%s", sha1);
|
|
|
|
free (sha1);
|
|
|
|
|
|
|
|
return compressed;
|
|
|
|
}
|
|
|
|
|
2009-10-22 00:37:51 +02:00
|
|
|
notmuch_message_t *
|
|
|
|
notmuch_database_find_message (notmuch_database_t *notmuch,
|
|
|
|
const char *message_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: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
|
|
|
|
2010-06-04 21:39:36 +02:00
|
|
|
if (strlen (message_id) > NOTMUCH_MESSAGE_ID_MAX)
|
|
|
|
message_id = _message_id_compressed (notmuch, message_id);
|
|
|
|
|
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)
|
|
|
|
return NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
return _notmuch_message_create (notmuch, notmuch, doc_id, NULL);
|
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
fprintf (stderr, "A Xapian exception occurred finding message: %s.\n",
|
|
|
|
error.get_msg().c_str());
|
|
|
|
notmuch->exception_reported = TRUE;
|
|
|
|
return NULL;
|
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
/* Advance 'str' past any whitespace or RFC 822 comments. A comment is
|
|
|
|
* a (potentially nested) parenthesized sequence with '\' used to
|
|
|
|
* escape any character (including parentheses).
|
|
|
|
*
|
|
|
|
* If the sequence to be skipped continues to the end of the string,
|
|
|
|
* then 'str' will be left pointing at the final terminating '\0'
|
|
|
|
* character.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
skip_space_and_comments (const char **str)
|
|
|
|
{
|
|
|
|
const char *s;
|
|
|
|
|
|
|
|
s = *str;
|
|
|
|
while (*s && (isspace (*s) || *s == '(')) {
|
|
|
|
while (*s && isspace (*s))
|
|
|
|
s++;
|
|
|
|
if (*s == '(') {
|
|
|
|
int nesting = 1;
|
|
|
|
s++;
|
|
|
|
while (*s && nesting) {
|
2009-11-22 00:14:39 +01:00
|
|
|
if (*s == '(') {
|
2009-10-19 21:54:40 +02:00
|
|
|
nesting++;
|
2009-11-22 00:14:39 +01:00
|
|
|
} else if (*s == ')') {
|
2009-10-19 21:54:40 +02:00
|
|
|
nesting--;
|
2009-11-22 00:14:39 +01:00
|
|
|
} else if (*s == '\\') {
|
2009-10-19 21:54:40 +02:00
|
|
|
if (*(s+1))
|
|
|
|
s++;
|
2009-11-22 00:14:39 +01:00
|
|
|
}
|
2009-10-19 21:54:40 +02:00
|
|
|
s++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
*str = s;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Parse an RFC 822 message-id, discarding whitespace, any RFC 822
|
|
|
|
* comments, and the '<' and '>' delimeters.
|
|
|
|
*
|
|
|
|
* If not NULL, then *next will be made to point to the first character
|
|
|
|
* not parsed, (possibly pointing to the final '\0' terminator.
|
|
|
|
*
|
2009-10-26 23:17:10 +01:00
|
|
|
* Returns a newly talloc'ed string belonging to 'ctx'.
|
2009-10-19 21:54:40 +02:00
|
|
|
*
|
|
|
|
* Returns NULL if there is any error parsing the message-id. */
|
2009-11-18 03:50:13 +01:00
|
|
|
static char *
|
2009-11-16 05:21:43 +01:00
|
|
|
_parse_message_id (void *ctx, const char *message_id, const char **next)
|
2009-10-19 21:54:40 +02:00
|
|
|
{
|
|
|
|
const char *s, *end;
|
2009-10-21 19:07:34 +02:00
|
|
|
char *result;
|
2009-10-19 21:54:40 +02:00
|
|
|
|
2009-11-20 21:46:37 +01:00
|
|
|
if (message_id == NULL || *message_id == '\0')
|
2009-10-19 21:54:40 +02:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
s = message_id;
|
|
|
|
|
|
|
|
skip_space_and_comments (&s);
|
|
|
|
|
|
|
|
/* Skip any unstructured text as well. */
|
|
|
|
while (*s && *s != '<')
|
|
|
|
s++;
|
|
|
|
|
|
|
|
if (*s == '<') {
|
|
|
|
s++;
|
|
|
|
} else {
|
|
|
|
if (next)
|
|
|
|
*next = s;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
skip_space_and_comments (&s);
|
|
|
|
|
|
|
|
end = s;
|
|
|
|
while (*end && *end != '>')
|
|
|
|
end++;
|
|
|
|
if (next) {
|
|
|
|
if (*end)
|
|
|
|
*next = end + 1;
|
|
|
|
else
|
|
|
|
*next = end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (end > s && *end == '>')
|
|
|
|
end--;
|
2009-10-21 19:07:34 +02:00
|
|
|
if (end <= s)
|
2009-10-19 21:54:40 +02:00
|
|
|
return NULL;
|
2009-10-21 19:07:34 +02:00
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
result = talloc_strndup (ctx, s, end - s + 1);
|
2009-10-21 19:07:34 +02:00
|
|
|
|
|
|
|
/* Finally, collapse any whitespace that is within the message-id
|
|
|
|
* itself. */
|
|
|
|
{
|
|
|
|
char *r;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
for (r = result, len = strlen (r); *r; r++, len--)
|
|
|
|
if (*r == ' ' || *r == '\t')
|
|
|
|
memmove (r, r+1, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
2009-10-19 21:54:40 +02:00
|
|
|
}
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
/* Parse a References header value, putting a (talloc'ed under 'ctx')
|
2009-11-18 02:20:32 +01:00
|
|
|
* copy of each referenced message-id into 'hash'.
|
|
|
|
*
|
|
|
|
* We explicitly avoid including any reference identical to
|
|
|
|
* 'message_id' in the result (to avoid mass confusion when a single
|
|
|
|
* message references itself cyclically---and yes, mail messages are
|
|
|
|
* not infrequent in the wild that do this---don't ask me why).
|
|
|
|
*/
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
static void
|
2009-10-26 23:17:10 +01:00
|
|
|
parse_references (void *ctx,
|
2009-11-18 02:20:32 +01:00
|
|
|
const char *message_id,
|
2009-10-26 23:17:10 +01:00
|
|
|
GHashTable *hash,
|
2009-10-19 21:54:40 +02:00
|
|
|
const char *refs)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2009-10-19 21:54:40 +02:00
|
|
|
char *ref;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-11-20 21:46:37 +01:00
|
|
|
if (refs == NULL || *refs == '\0')
|
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
|
|
|
return;
|
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
while (*refs) {
|
2009-11-16 05:21:43 +01:00
|
|
|
ref = _parse_message_id (ctx, refs, &refs);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-11-18 02:20:32 +01:00
|
|
|
if (ref && strcmp (ref, message_id))
|
2009-10-25 22:54:13 +01:00
|
|
|
g_hash_table_insert (hash, ref, NULL);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_database_t *
|
|
|
|
notmuch_database_create (const char *path)
|
|
|
|
{
|
2009-10-20 18:56:25 +02:00
|
|
|
notmuch_database_t *notmuch = NULL;
|
|
|
|
char *notmuch_path = 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) {
|
|
|
|
fprintf (stderr, "Error: Cannot create a database for a NULL path.\n");
|
|
|
|
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) {
|
|
|
|
fprintf (stderr, "Error: Cannot create database at %s: %s.\n",
|
|
|
|
path, strerror (errno));
|
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)) {
|
|
|
|
fprintf (stderr, "Error: Cannot create database at %s: Not a directory.\n",
|
|
|
|
path);
|
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) {
|
|
|
|
fprintf (stderr, "Error: Cannot create directory %s: %s.\n",
|
|
|
|
notmuch_path, strerror (errno));
|
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-11-21 20:54:25 +01:00
|
|
|
notmuch = notmuch_database_open (path,
|
2009-11-21 22:10:18 +01:00
|
|
|
NOTMUCH_DATABASE_MODE_READ_WRITE);
|
2010-01-08 03:26:31 +01:00
|
|
|
notmuch_database_upgrade (notmuch, NULL, 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
|
|
|
|
2009-10-20 18:56:25 +02:00
|
|
|
return 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
|
|
|
}
|
|
|
|
|
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) {
|
|
|
|
fprintf (stderr, "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;
|
|
|
|
}
|
|
|
|
|
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_t *
|
2009-11-21 20:54:25 +01:00
|
|
|
notmuch_database_open (const char *path,
|
|
|
|
notmuch_database_mode_t mode)
|
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-20 18:56:25 +02:00
|
|
|
notmuch_database_t *notmuch = NULL;
|
|
|
|
char *notmuch_path = NULL, *xapian_path = 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;
|
2009-10-20 18:56:25 +02:00
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
if (asprintf (¬much_path, "%s/%s", path, ".notmuch") == -1) {
|
|
|
|
notmuch_path = NULL;
|
|
|
|
fprintf (stderr, "Out of memory\n");
|
|
|
|
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) {
|
2009-10-20 19:14:00 +02:00
|
|
|
fprintf (stderr, "Error opening database at %s: %s\n",
|
|
|
|
notmuch_path, strerror (errno));
|
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
|
|
|
if (asprintf (&xapian_path, "%s/%s", notmuch_path, "xapian") == -1) {
|
|
|
|
xapian_path = NULL;
|
|
|
|
fprintf (stderr, "Out of memory\n");
|
|
|
|
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-21 23:00:37 +02:00
|
|
|
notmuch = talloc (NULL, notmuch_database_t);
|
2009-11-22 03:54:20 +01:00
|
|
|
notmuch->exception_reported = FALSE;
|
2009-10-21 23:00:37 +02:00
|
|
|
notmuch->path = talloc_strdup (notmuch, path);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-29 00:50:14 +01:00
|
|
|
if (notmuch->path[strlen (notmuch->path) - 1] == '/')
|
|
|
|
notmuch->path[strlen (notmuch->path) - 1] = '\0';
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
notmuch->needs_upgrade = FALSE;
|
2009-11-21 20:54:25 +01:00
|
|
|
notmuch->mode = mode;
|
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;
|
|
|
|
|
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,
|
|
|
|
Xapian::DB_CREATE_OR_OPEN);
|
2010-01-08 03:26:31 +01:00
|
|
|
version = notmuch_database_get_version (notmuch);
|
|
|
|
|
|
|
|
if (version > NOTMUCH_DATABASE_VERSION) {
|
|
|
|
fprintf (stderr,
|
|
|
|
"Error: Notmuch database at %s\n"
|
|
|
|
" has a newer database format version (%u) than supported by this\n"
|
|
|
|
" version of notmuch (%u). Refusing to open this database in\n"
|
|
|
|
" read-write mode.\n",
|
|
|
|
notmuch_path, version, NOTMUCH_DATABASE_VERSION);
|
|
|
|
notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
|
|
|
|
notmuch_database_close (notmuch);
|
|
|
|
notmuch = NULL;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (version < NOTMUCH_DATABASE_VERSION)
|
|
|
|
notmuch->needs_upgrade = TRUE;
|
2009-11-21 20:54:25 +01:00
|
|
|
} else {
|
|
|
|
notmuch->xapian_db = new Xapian::Database (xapian_path);
|
2010-01-08 03:26:31 +01:00
|
|
|
version = notmuch_database_get_version (notmuch);
|
|
|
|
if (version > NOTMUCH_DATABASE_VERSION)
|
|
|
|
{
|
|
|
|
fprintf (stderr,
|
|
|
|
"Warning: Notmuch database at %s\n"
|
|
|
|
" has a newer database format version (%u) than supported by this\n"
|
|
|
|
" version of notmuch (%u). Some operations may behave incorrectly,\n"
|
|
|
|
" (but the database will not be harmed since it is being opened\n"
|
|
|
|
" in read-only mode).\n",
|
|
|
|
notmuch_path, version, NOTMUCH_DATABASE_VERSION);
|
|
|
|
}
|
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);
|
|
|
|
}
|
|
|
|
|
2009-10-21 09:35:56 +02:00
|
|
|
notmuch->query_parser = new Xapian::QueryParser;
|
2009-10-28 18:42:07 +01:00
|
|
|
notmuch->term_gen = new Xapian::TermGenerator;
|
|
|
|
notmuch->term_gen->set_stemmer (Xapian::Stem ("english"));
|
2009-11-23 16:58:35 +01:00
|
|
|
notmuch->value_range_processor = new Xapian::NumberValueRangeProcessor (NOTMUCH_VALUE_TIMESTAMP);
|
2009-10-28 18:42:07 +01:00
|
|
|
|
2009-10-21 09:35:56 +02:00
|
|
|
notmuch->query_parser->set_default_op (Xapian::Query::OP_AND);
|
|
|
|
notmuch->query_parser->set_database (*notmuch->xapian_db);
|
2009-10-28 18:42:07 +01:00
|
|
|
notmuch->query_parser->set_stemmer (Xapian::Stem ("english"));
|
|
|
|
notmuch->query_parser->set_stemming_strategy (Xapian::QueryParser::STEM_SOME);
|
2009-11-23 16:58:35 +01:00
|
|
|
notmuch->query_parser->add_valuerangeprocessor (notmuch->value_range_processor);
|
2009-10-25 06:38:43 +01:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE (BOOLEAN_PREFIX_EXTERNAL); i++) {
|
|
|
|
prefix_t *prefix = &BOOLEAN_PREFIX_EXTERNAL[i];
|
|
|
|
notmuch->query_parser->add_boolean_prefix (prefix->name,
|
|
|
|
prefix->prefix);
|
|
|
|
}
|
2009-10-28 18:42:07 +01:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE (PROBABILISTIC_PREFIX); i++) {
|
|
|
|
prefix_t *prefix = &PROBABILISTIC_PREFIX[i];
|
|
|
|
notmuch->query_parser->add_prefix (prefix->name, prefix->prefix);
|
|
|
|
}
|
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) {
|
2009-11-22 03:41:30 +01:00
|
|
|
fprintf (stderr, "A Xapian exception occurred opening database: %s\n",
|
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
|
|
|
error.get_msg().c_str());
|
2009-10-28 07:57:37 +01:00
|
|
|
notmuch = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
2009-11-22 00:14:39 +01:00
|
|
|
|
2009-10-20 18:56:25 +02:00
|
|
|
DONE:
|
|
|
|
if (notmuch_path)
|
|
|
|
free (notmuch_path);
|
|
|
|
if (xapian_path)
|
|
|
|
free (xapian_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
|
|
|
|
|
|
|
return notmuch;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
notmuch_database_close (notmuch_database_t *notmuch)
|
|
|
|
{
|
2009-11-22 03:54:20 +01:00
|
|
|
try {
|
|
|
|
if (notmuch->mode == NOTMUCH_DATABASE_MODE_READ_WRITE)
|
|
|
|
(static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db))->flush ();
|
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
if (! notmuch->exception_reported) {
|
|
|
|
fprintf (stderr, "Error: A Xapian exception occurred flushing database: %s\n",
|
|
|
|
error.get_msg().c_str());
|
|
|
|
}
|
|
|
|
}
|
2009-10-28 00:17:22 +01:00
|
|
|
|
2009-10-28 18:42:07 +01:00
|
|
|
delete notmuch->term_gen;
|
2009-10-21 09:35:56 +02:00
|
|
|
delete notmuch->query_parser;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
delete notmuch->xapian_db;
|
2009-11-23 16:58:35 +01:00
|
|
|
delete notmuch->value_range_processor;
|
2009-10-21 23:00:37 +02:00
|
|
|
talloc_free (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
|
|
|
}
|
|
|
|
|
|
|
|
const char *
|
|
|
|
notmuch_database_get_path (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
return notmuch->path;
|
|
|
|
}
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
unsigned int
|
|
|
|
notmuch_database_get_version (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
unsigned int version;
|
|
|
|
string version_string;
|
|
|
|
const char *str;
|
|
|
|
char *end;
|
|
|
|
|
|
|
|
version_string = notmuch->xapian_db->get_metadata ("version");
|
|
|
|
if (version_string.empty ())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
str = version_string.c_str ();
|
|
|
|
if (str == NULL || *str == '\0')
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
version = strtoul (str, &end, 10);
|
|
|
|
if (*end != '\0')
|
|
|
|
INTERNAL_ERROR ("Malformed database version: %s", str);
|
|
|
|
|
|
|
|
return version;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_bool_t
|
|
|
|
notmuch_database_needs_upgrade (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
return notmuch->needs_upgrade;
|
|
|
|
}
|
|
|
|
|
|
|
|
static volatile sig_atomic_t do_progress_notify = 0;
|
|
|
|
|
|
|
|
static void
|
|
|
|
handle_sigalrm (unused (int signal))
|
|
|
|
{
|
|
|
|
do_progress_notify = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Upgrade the current database.
|
|
|
|
*
|
|
|
|
* After opening a database in read-write mode, the client should
|
|
|
|
* check if an upgrade is needed (notmuch_database_needs_upgrade) and
|
|
|
|
* if so, upgrade with this function before making any modifications.
|
|
|
|
*
|
|
|
|
* The optional progress_notify callback can be used by the caller to
|
|
|
|
* provide progress indication to the user. If non-NULL it will be
|
|
|
|
* called periodically with 'count' as the number of messages upgraded
|
|
|
|
* so far and 'total' the overall number of messages that will be
|
|
|
|
* converted.
|
|
|
|
*/
|
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_upgrade (notmuch_database_t *notmuch,
|
|
|
|
void (*progress_notify) (void *closure,
|
2010-01-10 02:38:23 +01:00
|
|
|
double progress),
|
2010-01-08 03:26:31 +01:00
|
|
|
void *closure)
|
|
|
|
{
|
|
|
|
Xapian::WritableDatabase *db;
|
|
|
|
struct sigaction action;
|
|
|
|
struct itimerval timerval;
|
|
|
|
notmuch_bool_t timer_is_active = FALSE;
|
|
|
|
unsigned int version;
|
|
|
|
notmuch_status_t status;
|
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);
|
|
|
|
|
|
|
|
version = notmuch_database_get_version (notmuch);
|
|
|
|
|
|
|
|
if (version >= NOTMUCH_DATABASE_VERSION)
|
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
|
|
|
|
if (progress_notify) {
|
|
|
|
/* Setup our handler for SIGALRM */
|
|
|
|
memset (&action, 0, sizeof (struct sigaction));
|
|
|
|
action.sa_handler = handle_sigalrm;
|
|
|
|
sigemptyset (&action.sa_mask);
|
|
|
|
action.sa_flags = SA_RESTART;
|
|
|
|
sigaction (SIGALRM, &action, NULL);
|
|
|
|
|
|
|
|
/* Then start a timer to send SIGALRM once per second. */
|
|
|
|
timerval.it_interval.tv_sec = 1;
|
|
|
|
timerval.it_interval.tv_usec = 0;
|
|
|
|
timerval.it_value.tv_sec = 1;
|
|
|
|
timerval.it_value.tv_usec = 0;
|
|
|
|
setitimer (ITIMER_REAL, &timerval, NULL);
|
|
|
|
|
|
|
|
timer_is_active = TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Before version 1, each message document had its filename in the
|
2010-01-09 20:13:12 +01:00
|
|
|
* data field. Copy that into the new format by calling
|
2010-01-08 03:26:31 +01:00
|
|
|
* notmuch_message_add_filename.
|
|
|
|
*/
|
|
|
|
if (version < 1) {
|
|
|
|
notmuch_query_t *query = notmuch_query_create (notmuch, "");
|
|
|
|
notmuch_messages_t *messages;
|
|
|
|
notmuch_message_t *message;
|
2010-01-09 20:13:12 +01:00
|
|
|
char *filename;
|
2010-01-10 02:38:23 +01:00
|
|
|
Xapian::TermIterator t, t_end;
|
2010-01-08 03:26:31 +01:00
|
|
|
|
|
|
|
total = notmuch_query_count_messages (query);
|
|
|
|
|
|
|
|
for (messages = notmuch_query_search_messages (query);
|
2010-03-09 18:22:29 +01:00
|
|
|
notmuch_messages_valid (messages);
|
|
|
|
notmuch_messages_move_to_next (messages))
|
2010-01-08 03:26:31 +01:00
|
|
|
{
|
2010-01-08 06:24:44 +01:00
|
|
|
if (do_progress_notify) {
|
2010-01-10 02:38:23 +01:00
|
|
|
progress_notify (closure, (double) count / total);
|
2010-01-08 06:24:44 +01:00
|
|
|
do_progress_notify = 0;
|
|
|
|
}
|
2010-01-08 03:26:31 +01:00
|
|
|
|
|
|
|
message = notmuch_messages_get (messages);
|
|
|
|
|
2010-01-09 20:13:12 +01:00
|
|
|
filename = _notmuch_message_talloc_copy_data (message);
|
|
|
|
if (filename && *filename != '\0') {
|
|
|
|
_notmuch_message_add_filename (message, filename);
|
|
|
|
_notmuch_message_sync (message);
|
|
|
|
}
|
|
|
|
talloc_free (filename);
|
|
|
|
|
|
|
|
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);
|
2010-01-08 03:26:31 +01:00
|
|
|
|
2010-01-10 02:38:23 +01:00
|
|
|
/* Also, before version 1 we stored directory timestamps in
|
|
|
|
* XTIMESTAMP documents instead of the current XDIRECTORY
|
|
|
|
* documents. So copy those as well. */
|
2010-01-08 03:26:31 +01:00
|
|
|
|
|
|
|
t_end = notmuch->xapian_db->allterms_end ("XTIMESTAMP");
|
|
|
|
|
|
|
|
for (t = notmuch->xapian_db->allterms_begin ("XTIMESTAMP");
|
|
|
|
t != t_end;
|
|
|
|
t++)
|
|
|
|
{
|
|
|
|
Xapian::PostingIterator p, p_end;
|
|
|
|
std::string term = *t;
|
|
|
|
|
|
|
|
p_end = notmuch->xapian_db->postlist_end (term);
|
|
|
|
|
|
|
|
for (p = notmuch->xapian_db->postlist_begin (term);
|
|
|
|
p != p_end;
|
|
|
|
p++)
|
|
|
|
{
|
|
|
|
Xapian::Document document;
|
|
|
|
time_t mtime;
|
|
|
|
notmuch_directory_t *directory;
|
|
|
|
|
2010-01-10 02:38:23 +01:00
|
|
|
if (do_progress_notify) {
|
|
|
|
progress_notify (closure, (double) count / total);
|
|
|
|
do_progress_notify = 0;
|
|
|
|
}
|
|
|
|
|
2010-01-08 03:26:31 +01:00
|
|
|
document = find_document_for_doc_id (notmuch, *p);
|
|
|
|
mtime = Xapian::sortable_unserialise (
|
|
|
|
document.get_value (NOTMUCH_VALUE_TIMESTAMP));
|
|
|
|
|
|
|
|
directory = notmuch_database_get_directory (notmuch,
|
|
|
|
term.c_str() + 10);
|
|
|
|
notmuch_directory_set_mtime (directory, mtime);
|
|
|
|
notmuch_directory_destroy (directory);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
|
|
|
|
db->flush ();
|
|
|
|
|
2010-01-09 20:13:12 +01:00
|
|
|
/* Now that the upgrade is complete we can remove the old data
|
|
|
|
* and documents that are no longer needed. */
|
|
|
|
if (version < 1) {
|
|
|
|
notmuch_query_t *query = notmuch_query_create (notmuch, "");
|
|
|
|
notmuch_messages_t *messages;
|
|
|
|
notmuch_message_t *message;
|
|
|
|
char *filename;
|
|
|
|
|
|
|
|
for (messages = notmuch_query_search_messages (query);
|
2010-03-09 18:22:29 +01:00
|
|
|
notmuch_messages_valid (messages);
|
|
|
|
notmuch_messages_move_to_next (messages))
|
2010-01-09 20:13:12 +01:00
|
|
|
{
|
|
|
|
if (do_progress_notify) {
|
2010-01-10 02:38:23 +01:00
|
|
|
progress_notify (closure, (double) count / total);
|
2010-01-09 20:13:12 +01:00
|
|
|
do_progress_notify = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
message = notmuch_messages_get (messages);
|
|
|
|
|
|
|
|
filename = _notmuch_message_talloc_copy_data (message);
|
|
|
|
if (filename && *filename != '\0') {
|
|
|
|
_notmuch_message_clear_data (message);
|
|
|
|
_notmuch_message_sync (message);
|
|
|
|
}
|
|
|
|
talloc_free (filename);
|
|
|
|
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_query_destroy (query);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (version < 1) {
|
|
|
|
Xapian::TermIterator t, t_end;
|
|
|
|
|
|
|
|
t_end = notmuch->xapian_db->allterms_end ("XTIMESTAMP");
|
|
|
|
|
|
|
|
for (t = notmuch->xapian_db->allterms_begin ("XTIMESTAMP");
|
|
|
|
t != t_end;
|
|
|
|
t++)
|
|
|
|
{
|
|
|
|
Xapian::PostingIterator p, p_end;
|
|
|
|
std::string term = *t;
|
|
|
|
|
|
|
|
p_end = notmuch->xapian_db->postlist_end (term);
|
|
|
|
|
|
|
|
for (p = notmuch->xapian_db->postlist_begin (term);
|
|
|
|
p != p_end;
|
|
|
|
p++)
|
|
|
|
{
|
2010-01-10 02:38:23 +01:00
|
|
|
if (do_progress_notify) {
|
|
|
|
progress_notify (closure, (double) count / total);
|
|
|
|
do_progress_notify = 0;
|
|
|
|
}
|
|
|
|
|
2010-01-09 20:13:12 +01:00
|
|
|
db->delete_document (*p);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
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)
|
2009-12-17 23:33:34 +01: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. */
|
|
|
|
while (slash != path) {
|
|
|
|
if (*slash != '/')
|
|
|
|
break;
|
|
|
|
|
|
|
|
--slash;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Then, find a slash. */
|
|
|
|
while (slash != path) {
|
|
|
|
if (*slash == '/')
|
|
|
|
break;
|
|
|
|
|
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. */
|
|
|
|
while (slash != path) {
|
|
|
|
if (*slash != '/')
|
|
|
|
break;
|
|
|
|
|
|
|
|
--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)
|
|
|
|
*directory = talloc_strndup (ctx, path, slash - path + 1);
|
|
|
|
}
|
2009-12-19 22:20:26 +01:00
|
|
|
|
2009-12-21 17:14:52 +01:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_status_t
|
|
|
|
_notmuch_database_find_directory_id (notmuch_database_t *notmuch,
|
|
|
|
const char *path,
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2010-01-05 22:29:23 +01:00
|
|
|
directory = _notmuch_directory_create (notmuch, path, &status);
|
|
|
|
if (status) {
|
|
|
|
*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
|
|
|
*
|
|
|
|
* The necessary directory documents will be created in the database
|
|
|
|
* as needed.
|
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,
|
|
|
|
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;
|
|
|
|
|
|
|
|
status = _notmuch_database_find_directory_id (notmuch, directory,
|
|
|
|
&directory_id);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
*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.
|
|
|
|
*
|
|
|
|
* The return value will be a pointer to the originl path contents,
|
|
|
|
* and will be either the original string (if 'path' was relative) or
|
|
|
|
* a portion of the string (if path was absolute and begins with the
|
|
|
|
* database path).
|
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
_notmuch_database_relative_path (notmuch_database_t *notmuch,
|
|
|
|
const char *path)
|
|
|
|
{
|
|
|
|
const char *db_path, *relative;
|
|
|
|
unsigned int db_path_len;
|
|
|
|
|
|
|
|
db_path = notmuch_database_get_path (notmuch);
|
|
|
|
db_path_len = strlen (db_path);
|
|
|
|
|
|
|
|
relative = path;
|
|
|
|
|
|
|
|
if (*relative == '/') {
|
|
|
|
while (*relative == '/' && *(relative+1) == '/')
|
|
|
|
relative++;
|
|
|
|
|
|
|
|
if (strncmp (relative, db_path, db_path_len) == 0)
|
|
|
|
{
|
|
|
|
relative += db_path_len;
|
|
|
|
while (*relative == '/')
|
|
|
|
relative++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return relative;
|
|
|
|
}
|
|
|
|
|
2010-01-05 22:29:23 +01:00
|
|
|
notmuch_directory_t *
|
|
|
|
notmuch_database_get_directory (notmuch_database_t *notmuch,
|
|
|
|
const char *path)
|
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
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
try {
|
|
|
|
return _notmuch_directory_create (notmuch, path, &status);
|
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
fprintf (stderr, "A Xapian exception occurred getting directory: %s.\n",
|
|
|
|
error.get_msg().c_str());
|
|
|
|
notmuch->exception_reported = TRUE;
|
|
|
|
return NULL;
|
|
|
|
}
|
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)
|
|
|
|
INTERNAL_ERROR ("Xapian document IDs are exhausted.\n");
|
|
|
|
|
|
|
|
return notmuch->last_doc_id;
|
|
|
|
}
|
|
|
|
|
2010-03-13 22:27:57 +01:00
|
|
|
static const char *
|
|
|
|
_notmuch_database_generate_thread_id (notmuch_database_t *notmuch)
|
|
|
|
{
|
|
|
|
/* 16 bytes (+ terminator) for hexadecimal representation of
|
|
|
|
* a 64-bit integer. */
|
|
|
|
static char thread_id[17];
|
|
|
|
Xapian::WritableDatabase *db;
|
|
|
|
|
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
|
|
|
|
notmuch->last_thread_id++;
|
|
|
|
|
|
|
|
sprintf (thread_id, "%016" PRIx64, notmuch->last_thread_id);
|
|
|
|
|
|
|
|
db->set_metadata ("last_thread_id", thread_id);
|
|
|
|
|
|
|
|
return thread_id;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *
|
|
|
|
_get_metadata_thread_id_key (void *ctx, const char *message_id)
|
|
|
|
{
|
2010-06-04 21:39:36 +02:00
|
|
|
if (strlen (message_id) > NOTMUCH_MESSAGE_ID_MAX)
|
|
|
|
message_id = _message_id_compressed (ctx, message_id);
|
|
|
|
|
|
|
|
return talloc_asprintf (ctx, NOTMUCH_METADATA_THREAD_ID_PREFIX "%s",
|
|
|
|
message_id);
|
2010-03-13 22:27:57 +01:00
|
|
|
}
|
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
/* Find the thread ID to which the message with 'message_id' belongs.
|
2009-10-25 19:03:55 +01:00
|
|
|
*
|
2010-04-12 23:19:15 +02:00
|
|
|
* Always returns a newly talloced string belonging to 'ctx'.
|
2009-10-25 19:03:55 +01:00
|
|
|
*
|
2010-04-12 23:19:15 +02:00
|
|
|
* Note: If there is no message in the database with the given
|
|
|
|
* 'message_id' then a new thread_id will be allocated for this
|
|
|
|
* message and stored in the database metadata, (where this same
|
|
|
|
* thread ID can be looked up if the message is added to the database
|
|
|
|
* later).
|
2009-10-25 19:03:55 +01:00
|
|
|
*/
|
2009-10-25 23:58:05 +01:00
|
|
|
static const char *
|
2009-10-25 22:54:13 +01:00
|
|
|
_resolve_message_id_to_thread_id (notmuch_database_t *notmuch,
|
|
|
|
void *ctx,
|
|
|
|
const char *message_id)
|
|
|
|
{
|
|
|
|
notmuch_message_t *message;
|
2010-04-12 23:29:36 +02:00
|
|
|
string thread_id_string;
|
|
|
|
const char *thread_id;
|
|
|
|
char *metadata_key;
|
|
|
|
Xapian::WritableDatabase *db;
|
2009-10-25 22:54:13 +01:00
|
|
|
|
|
|
|
message = notmuch_database_find_message (notmuch, message_id);
|
|
|
|
|
2010-04-12 23:29:36 +02:00
|
|
|
if (message) {
|
|
|
|
thread_id = talloc_steal (ctx, notmuch_message_get_thread_id (message));
|
2009-10-25 22:54:13 +01:00
|
|
|
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
|
2010-04-12 23:29:36 +02:00
|
|
|
return thread_id;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Message has not been seen yet.
|
|
|
|
*
|
|
|
|
* We may have seen a reference to it already, in which case, we
|
|
|
|
* can return the thread ID stored in the metadata. Otherwise, we
|
|
|
|
* generate a new thread ID and store it there.
|
|
|
|
*/
|
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
metadata_key = _get_metadata_thread_id_key (ctx, message_id);
|
|
|
|
thread_id_string = notmuch->xapian_db->get_metadata (metadata_key);
|
|
|
|
|
|
|
|
if (thread_id_string.empty()) {
|
|
|
|
thread_id = _notmuch_database_generate_thread_id (notmuch);
|
|
|
|
db->set_metadata (metadata_key, thread_id);
|
|
|
|
} else {
|
|
|
|
thread_id = thread_id_string.c_str();
|
|
|
|
}
|
|
|
|
|
|
|
|
talloc_free (metadata_key);
|
|
|
|
|
|
|
|
return thread_id;
|
2009-10-25 22:54:13 +01:00
|
|
|
}
|
|
|
|
|
2009-10-25 19:03:55 +01:00
|
|
|
static notmuch_status_t
|
2009-10-25 22:54:13 +01:00
|
|
|
_merge_threads (notmuch_database_t *notmuch,
|
|
|
|
const char *winner_thread_id,
|
|
|
|
const char *loser_thread_id)
|
|
|
|
{
|
|
|
|
Xapian::PostingIterator loser, loser_end;
|
|
|
|
notmuch_message_t *message = NULL;
|
|
|
|
notmuch_private_status_t private_status;
|
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
|
|
|
|
|
|
|
|
find_doc_ids (notmuch, "thread", loser_thread_id, &loser, &loser_end);
|
|
|
|
|
|
|
|
for ( ; loser != loser_end; loser++) {
|
|
|
|
message = _notmuch_message_create (notmuch, notmuch,
|
|
|
|
*loser, &private_status);
|
|
|
|
if (message == NULL) {
|
|
|
|
ret = COERCE_STATUS (private_status,
|
|
|
|
"Cannot find document for doc_id from query");
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
_notmuch_message_remove_term (message, "thread", loser_thread_id);
|
|
|
|
_notmuch_message_add_term (message, "thread", winner_thread_id);
|
|
|
|
_notmuch_message_sync (message);
|
|
|
|
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
message = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
DONE:
|
|
|
|
if (message)
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
static void
|
|
|
|
_my_talloc_free_for_g_hash (void *ptr)
|
|
|
|
{
|
|
|
|
talloc_free (ptr);
|
|
|
|
}
|
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
static notmuch_status_t
|
|
|
|
_notmuch_database_link_message_to_parents (notmuch_database_t *notmuch,
|
|
|
|
notmuch_message_t *message,
|
|
|
|
notmuch_message_file_t *message_file,
|
|
|
|
const char **thread_id)
|
2009-10-25 19:03:55 +01:00
|
|
|
{
|
2009-10-25 22:54:13 +01:00
|
|
|
GHashTable *parents = NULL;
|
2009-11-18 02:20:32 +01:00
|
|
|
const char *refs, *in_reply_to, *in_reply_to_message_id;
|
2009-10-25 22:54:13 +01:00
|
|
|
GList *l, *keys = NULL;
|
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
parents = g_hash_table_new_full (g_str_hash, g_str_equal,
|
2009-10-26 23:17:10 +01:00
|
|
|
_my_talloc_free_for_g_hash, NULL);
|
2009-10-25 19:03:55 +01:00
|
|
|
|
|
|
|
refs = notmuch_message_file_get_header (message_file, "references");
|
2009-11-18 02:20:32 +01:00
|
|
|
parse_references (message, notmuch_message_get_message_id (message),
|
|
|
|
parents, refs);
|
2009-10-25 19:03:55 +01:00
|
|
|
|
|
|
|
in_reply_to = notmuch_message_file_get_header (message_file, "in-reply-to");
|
2009-11-18 02:20:32 +01:00
|
|
|
parse_references (message, notmuch_message_get_message_id (message),
|
|
|
|
parents, in_reply_to);
|
|
|
|
|
|
|
|
/* Carefully avoid adding any self-referential in-reply-to term. */
|
|
|
|
in_reply_to_message_id = _parse_message_id (message, in_reply_to, NULL);
|
2009-11-18 10:36:30 +01:00
|
|
|
if (in_reply_to_message_id &&
|
|
|
|
strcmp (in_reply_to_message_id,
|
2009-11-18 02:20:32 +01:00
|
|
|
notmuch_message_get_message_id (message)))
|
|
|
|
{
|
|
|
|
_notmuch_message_add_term (message, "replyto",
|
|
|
|
_parse_message_id (message, in_reply_to, NULL));
|
|
|
|
}
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
keys = g_hash_table_get_keys (parents);
|
|
|
|
for (l = keys; l; l = l->next) {
|
|
|
|
char *parent_message_id;
|
|
|
|
const char *parent_thread_id;
|
|
|
|
|
|
|
|
parent_message_id = (char *) l->data;
|
2010-04-13 00:45:40 +02:00
|
|
|
|
|
|
|
_notmuch_message_add_term (message, "reference",
|
|
|
|
parent_message_id);
|
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
parent_thread_id = _resolve_message_id_to_thread_id (notmuch,
|
|
|
|
message,
|
|
|
|
parent_message_id);
|
|
|
|
|
2010-04-13 00:54:03 +02:00
|
|
|
if (*thread_id == NULL) {
|
|
|
|
*thread_id = talloc_strdup (message, parent_thread_id);
|
|
|
|
_notmuch_message_add_term (message, "thread", *thread_id);
|
|
|
|
} else if (strcmp (*thread_id, parent_thread_id)) {
|
|
|
|
ret = _merge_threads (notmuch, *thread_id, parent_thread_id);
|
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
2009-10-25 22:54:13 +01:00
|
|
|
}
|
|
|
|
}
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
DONE:
|
|
|
|
if (keys)
|
|
|
|
g_list_free (keys);
|
|
|
|
if (parents)
|
|
|
|
g_hash_table_unref (parents);
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
return ret;
|
|
|
|
}
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
static notmuch_status_t
|
|
|
|
_notmuch_database_link_message_to_children (notmuch_database_t *notmuch,
|
|
|
|
notmuch_message_t *message,
|
|
|
|
const char **thread_id)
|
|
|
|
{
|
|
|
|
const char *message_id = notmuch_message_get_message_id (message);
|
|
|
|
Xapian::PostingIterator child, children_end;
|
|
|
|
notmuch_message_t *child_message = NULL;
|
|
|
|
const char *child_thread_id;
|
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
|
|
|
|
notmuch_private_status_t private_status;
|
|
|
|
|
2009-11-18 03:44:02 +01:00
|
|
|
find_doc_ids (notmuch, "reference", message_id, &child, &children_end);
|
2009-10-25 22:54:13 +01:00
|
|
|
|
|
|
|
for ( ; child != children_end; child++) {
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
child_message = _notmuch_message_create (message, notmuch,
|
|
|
|
*child, &private_status);
|
|
|
|
if (child_message == NULL) {
|
|
|
|
ret = COERCE_STATUS (private_status,
|
|
|
|
"Cannot find document for doc_id from query");
|
|
|
|
goto DONE;
|
2009-10-25 19:03:55 +01:00
|
|
|
}
|
2009-10-25 22:54:13 +01:00
|
|
|
|
|
|
|
child_thread_id = notmuch_message_get_thread_id (child_message);
|
|
|
|
if (*thread_id == NULL) {
|
|
|
|
*thread_id = talloc_strdup (message, child_thread_id);
|
|
|
|
_notmuch_message_add_term (message, "thread", *thread_id);
|
|
|
|
} else if (strcmp (*thread_id, child_thread_id)) {
|
2009-11-18 03:44:02 +01:00
|
|
|
_notmuch_message_remove_term (child_message, "reference",
|
2009-10-25 22:54:13 +01:00
|
|
|
message_id);
|
|
|
|
_notmuch_message_sync (child_message);
|
|
|
|
ret = _merge_threads (notmuch, *thread_id, child_thread_id);
|
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_message_destroy (child_message);
|
|
|
|
child_message = NULL;
|
2009-10-25 19:03:55 +01:00
|
|
|
}
|
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
DONE:
|
|
|
|
if (child_message)
|
|
|
|
notmuch_message_destroy (child_message);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-10-25 22:54:13 +01:00
|
|
|
/* Given a (mostly empty) 'message' and its corresponding
|
|
|
|
* 'message_file' link it to existing threads in the database.
|
|
|
|
*
|
2010-04-12 23:35:25 +02:00
|
|
|
* The first check is in the metadata of the database to see if we
|
|
|
|
* have pre-allocated a thread_id in advance for this message, (which
|
|
|
|
* would have happened if a message was previously added that
|
|
|
|
* referenced this one).
|
|
|
|
*
|
|
|
|
* Second, we look at 'message_file' and its link-relevant headers
|
|
|
|
* (References and In-Reply-To) for message IDs.
|
|
|
|
*
|
|
|
|
* Finally, we look in the database for existing message that
|
|
|
|
* reference 'message'.
|
|
|
|
*
|
|
|
|
* In all cases, we assign to the current message the first thread_id
|
2010-02-08 20:33:33 +01:00
|
|
|
* found (through either parent or child). We will also merge any
|
|
|
|
* existing, distinct threads where this message belongs to both,
|
|
|
|
* (which is not uncommon when mesages are processed out of order).
|
2009-10-25 22:54:13 +01:00
|
|
|
*
|
2010-04-12 23:35:25 +02:00
|
|
|
* Finally, if no thread ID has been found through parent or child, we
|
|
|
|
* call _notmuch_message_generate_thread_id to generate a new thread
|
|
|
|
* ID. This should only happen for new, top-level messages, (no
|
|
|
|
* References or In-Reply-To header in this message, and no previously
|
|
|
|
* added message refers to this message).
|
2009-10-25 22:54:13 +01:00
|
|
|
*/
|
|
|
|
static notmuch_status_t
|
|
|
|
_notmuch_database_link_message (notmuch_database_t *notmuch,
|
|
|
|
notmuch_message_t *message,
|
|
|
|
notmuch_message_file_t *message_file)
|
|
|
|
{
|
2009-10-25 23:01:20 +01:00
|
|
|
notmuch_status_t status;
|
2010-04-12 23:41:34 +02:00
|
|
|
const char *message_id, *thread_id = NULL;
|
|
|
|
char *metadata_key;
|
|
|
|
string stored_id;
|
|
|
|
|
|
|
|
message_id = notmuch_message_get_message_id (message);
|
|
|
|
metadata_key = _get_metadata_thread_id_key (message, message_id);
|
|
|
|
|
2010-03-13 22:27:57 +01:00
|
|
|
/* Check if we have already seen related messages to this one.
|
|
|
|
* If we have then use the thread_id that we stored at that time.
|
|
|
|
*/
|
2010-04-12 23:41:34 +02:00
|
|
|
stored_id = notmuch->xapian_db->get_metadata (metadata_key);
|
|
|
|
if (! stored_id.empty()) {
|
|
|
|
Xapian::WritableDatabase *db;
|
|
|
|
|
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
|
|
|
|
/* Clear the metadata for this message ID. We don't need it
|
|
|
|
* anymore. */
|
2010-03-13 22:27:57 +01:00
|
|
|
db->set_metadata (metadata_key, "");
|
|
|
|
thread_id = stored_id.c_str();
|
2010-04-12 23:41:34 +02:00
|
|
|
|
2010-03-13 22:27:57 +01:00
|
|
|
_notmuch_message_add_term (message, "thread", thread_id);
|
|
|
|
}
|
|
|
|
talloc_free (metadata_key);
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2009-10-25 23:01:20 +01:00
|
|
|
status = _notmuch_database_link_message_to_parents (notmuch, message,
|
|
|
|
message_file,
|
|
|
|
&thread_id);
|
|
|
|
if (status)
|
|
|
|
return status;
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2009-10-25 23:01:20 +01:00
|
|
|
status = _notmuch_database_link_message_to_children (notmuch, message,
|
|
|
|
&thread_id);
|
|
|
|
if (status)
|
|
|
|
return status;
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2010-02-08 20:33:33 +01:00
|
|
|
/* If not part of any existing thread, generate a new thread ID. */
|
|
|
|
if (thread_id == NULL) {
|
|
|
|
thread_id = _notmuch_database_generate_thread_id (notmuch);
|
|
|
|
|
|
|
|
_notmuch_message_add_term (message, "thread", thread_id);
|
|
|
|
}
|
2009-10-25 22:54:13 +01:00
|
|
|
|
2009-10-25 23:01:20 +01:00
|
|
|
return NOTMUCH_STATUS_SUCCESS;
|
2009-10-25 19:03:55 +01:00
|
|
|
}
|
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_add_message (notmuch_database_t *notmuch,
|
2009-10-27 05:44:05 +01:00
|
|
|
const char *filename,
|
|
|
|
notmuch_message_t **message_ret)
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
{
|
2009-10-23 14:13:42 +02:00
|
|
|
notmuch_message_file_t *message_file;
|
2009-11-09 22:43:59 +01:00
|
|
|
notmuch_message_t *message = NULL;
|
2009-10-23 00:31:56 +02:00
|
|
|
notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;
|
2009-10-29 00:50:14 +01:00
|
|
|
notmuch_private_status_t private_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
|
|
|
|
2009-10-25 19:03:55 +01:00
|
|
|
const char *date, *header;
|
2009-10-29 00:50:14 +01:00
|
|
|
const char *from, *to, *subject;
|
2009-11-22 04:03:49 +01:00
|
|
|
char *message_id = NULL;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-28 00:19:20 +01:00
|
|
|
if (message_ret)
|
|
|
|
*message_ret = NULL;
|
|
|
|
|
2010-01-07 19:19:44 +01:00
|
|
|
ret = _notmuch_database_ensure_writable (notmuch);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2009-10-23 14:13:42 +02:00
|
|
|
message_file = notmuch_message_file_open (filename);
|
2010-01-07 19:19:44 +01:00
|
|
|
if (message_file == NULL)
|
|
|
|
return NOTMUCH_STATUS_FILE_ERROR;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-23 14:13:42 +02:00
|
|
|
notmuch_message_file_restrict_headers (message_file,
|
2009-10-21 00:09:51 +02:00
|
|
|
"date",
|
|
|
|
"from",
|
|
|
|
"in-reply-to",
|
|
|
|
"message-id",
|
|
|
|
"references",
|
|
|
|
"subject",
|
2009-10-23 00:34:47 +02:00
|
|
|
"to",
|
2009-10-21 00:09:51 +02:00
|
|
|
(char *) NULL);
|
2009-10-19 22:48:13 +02:00
|
|
|
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
try {
|
2009-10-28 21:35:10 +01:00
|
|
|
/* Before we do any real work, (especially before doing a
|
|
|
|
* potential SHA-1 computation on the entire file's contents),
|
|
|
|
* let's make sure that what we're looking at looks like an
|
|
|
|
* actual email message.
|
|
|
|
*/
|
|
|
|
from = notmuch_message_file_get_header (message_file, "from");
|
|
|
|
subject = notmuch_message_file_get_header (message_file, "subject");
|
|
|
|
to = notmuch_message_file_get_header (message_file, "to");
|
|
|
|
|
2009-11-20 21:46:37 +01:00
|
|
|
if ((from == NULL || *from == '\0') &&
|
|
|
|
(subject == NULL || *subject == '\0') &&
|
|
|
|
(to == NULL || *to == '\0'))
|
2009-10-28 21:35:10 +01:00
|
|
|
{
|
|
|
|
ret = NOTMUCH_STATUS_FILE_NOT_EMAIL;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now that we're sure it's mail, the first order of business
|
|
|
|
* is to find a message ID (or else create one ourselves). */
|
2009-10-23 15:00:10 +02:00
|
|
|
|
2009-10-23 14:13:42 +02:00
|
|
|
header = notmuch_message_file_get_header (message_file, "message-id");
|
2009-11-20 19:31:00 +01:00
|
|
|
if (header && *header != '\0') {
|
2009-11-16 05:21:43 +01:00
|
|
|
message_id = _parse_message_id (message_file, header, NULL);
|
2009-11-22 04:03:49 +01:00
|
|
|
|
2009-10-19 21:54:40 +02:00
|
|
|
/* So the header value isn't RFC-compliant, but it's
|
|
|
|
* better than no message-id at all. */
|
|
|
|
if (message_id == NULL)
|
2009-10-26 23:17:10 +01:00
|
|
|
message_id = talloc_strdup (message_file, header);
|
2009-11-22 04:03:49 +01:00
|
|
|
|
2010-06-04 21:39:36 +02:00
|
|
|
/* If a message ID is too long, substitute its sha1 instead. */
|
|
|
|
if (message_id && strlen (message_id) > NOTMUCH_MESSAGE_ID_MAX) {
|
|
|
|
char *compressed = _message_id_compressed (message_file,
|
|
|
|
message_id);
|
2009-11-22 04:03:49 +01:00
|
|
|
talloc_free (message_id);
|
2010-06-04 21:39:36 +02:00
|
|
|
message_id = compressed;
|
2009-11-22 04:03:49 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (message_id == NULL ) {
|
2009-10-23 00:31:56 +02:00
|
|
|
/* No message-id at all, let's generate one by taking a
|
|
|
|
* hash over the file's contents. */
|
|
|
|
char *sha1 = notmuch_sha1_of_file (filename);
|
|
|
|
|
|
|
|
/* If that failed too, something is really wrong. Give up. */
|
|
|
|
if (sha1 == NULL) {
|
|
|
|
ret = NOTMUCH_STATUS_FILE_ERROR;
|
|
|
|
goto DONE;
|
|
|
|
}
|
|
|
|
|
2009-10-26 23:17:10 +01:00
|
|
|
message_id = talloc_asprintf (message_file,
|
|
|
|
"notmuch-sha1-%s", sha1);
|
2009-10-23 00:31:56 +02:00
|
|
|
free (sha1);
|
2009-10-19 21:54:40 +02:00
|
|
|
}
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-23 15:00:10 +02:00
|
|
|
/* Now that we have a message ID, we get a message object,
|
|
|
|
* (which may or may not reference an existing document in the
|
|
|
|
* database). */
|
|
|
|
|
2009-11-17 18:04:14 +01:00
|
|
|
message = _notmuch_message_create_for_message_id (notmuch,
|
2009-10-25 17:47:21 +01:00
|
|
|
message_id,
|
2009-10-29 00:50:14 +01:00
|
|
|
&private_status);
|
2009-10-26 23:17:10 +01:00
|
|
|
|
|
|
|
talloc_free (message_id);
|
2009-10-25 19:03:55 +01:00
|
|
|
|
2009-11-20 21:02:11 +01:00
|
|
|
if (message == NULL) {
|
|
|
|
ret = COERCE_STATUS (private_status,
|
|
|
|
"Unexpected status value from _notmuch_message_create_for_message_id");
|
2009-10-25 17:47:21 +01:00
|
|
|
goto DONE;
|
2009-11-20 21:02:11 +01:00
|
|
|
}
|
2009-10-23 14:30:37 +02:00
|
|
|
|
2009-12-21 21:08:46 +01:00
|
|
|
_notmuch_message_add_filename (message, filename);
|
|
|
|
|
2009-10-29 00:50:14 +01:00
|
|
|
/* Is this a newly created message object? */
|
|
|
|
if (private_status == NOTMUCH_PRIVATE_STATUS_NO_DOCUMENT_FOUND) {
|
2009-10-23 15:00:10 +02:00
|
|
|
_notmuch_message_add_term (message, "type", "mail");
|
2009-10-23 14:30:37 +02:00
|
|
|
|
2009-12-21 21:08:46 +01:00
|
|
|
ret = _notmuch_database_link_message (notmuch, message,
|
|
|
|
message_file);
|
|
|
|
if (ret)
|
|
|
|
goto DONE;
|
2009-10-20 22:05:45 +02:00
|
|
|
|
2009-12-21 21:08:46 +01:00
|
|
|
date = notmuch_message_file_get_header (message_file, "date");
|
|
|
|
_notmuch_message_set_date (message, date);
|
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-21 21:08:46 +01:00
|
|
|
_notmuch_message_index_file (message, filename);
|
|
|
|
} else {
|
|
|
|
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
|
|
|
|
}
|
2009-10-28 18:42:07 +01:00
|
|
|
|
|
|
|
_notmuch_message_sync (message);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
2009-11-22 03:41:30 +01:00
|
|
|
fprintf (stderr, "A Xapian exception occurred adding message: %s.\n",
|
2010-04-24 16:22:34 +02:00
|
|
|
error.get_msg().c_str());
|
2009-11-22 03:54:20 +01:00
|
|
|
notmuch->exception_reported = TRUE;
|
2009-10-23 00:31:56 +02:00
|
|
|
ret = NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
|
|
|
goto DONE;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
|
|
|
|
2009-10-23 00:31:56 +02:00
|
|
|
DONE:
|
2009-10-27 05:44:05 +01:00
|
|
|
if (message) {
|
2009-10-28 00:19:20 +01:00
|
|
|
if (ret == NOTMUCH_STATUS_SUCCESS && message_ret)
|
2009-10-27 05:44:05 +01:00
|
|
|
*message_ret = message;
|
|
|
|
else
|
|
|
|
notmuch_message_destroy (message);
|
|
|
|
}
|
|
|
|
|
2009-10-23 14:13:42 +02:00
|
|
|
if (message_file)
|
|
|
|
notmuch_message_file_close (message_file);
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
|
2009-10-23 00:31:56 +02:00
|
|
|
return ret;
|
notmuch: Start actually adding messages to the index.
This is the beginning of the notmuch library as well, with its
interface in notmuch.h. So far we've got create, open, close, and
add_message (all with a notmuch_database prefix).
The current add_message function has already been whittled down from
what we have in notmuch-index-message to add only references,
message-id, and thread-id to the index, (that is---just enough to do
thread-linkage but nothing for full-text searching).
The concept here is to do something quickly so that the user can get
some data into notmuch and start using it. (The most interesting stuff
is then thread-linkage and labels like inbox and unread.) We can
defer the full-text indexing of the body of the messages for later,
(such as in the background while the user is reading mail).
The initial thread-stitching step is still slower than I would like.
We may have to stop using libgmime for this step as its overhead is
not worth it for the simple case of just parsing the message-id,
references, and in-reply-to headers.
2009-10-19 05:56:30 +02:00
|
|
|
}
|
2009-11-23 01:10:54 +01:00
|
|
|
|
2009-12-22 00:14:32 +01:00
|
|
|
notmuch_status_t
|
|
|
|
notmuch_database_remove_message (notmuch_database_t *notmuch,
|
|
|
|
const char *filename)
|
|
|
|
{
|
|
|
|
Xapian::WritableDatabase *db;
|
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;
|
|
|
|
Xapian::Document document;
|
|
|
|
notmuch_status_t status;
|
|
|
|
|
2010-01-07 19:19:44 +01:00
|
|
|
status = _notmuch_database_ensure_writable (notmuch);
|
|
|
|
if (status)
|
|
|
|
return status;
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
local = talloc_new (notmuch);
|
|
|
|
|
2009-12-22 00:14:32 +01:00
|
|
|
db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
|
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
try {
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
status = _notmuch_database_filename_to_direntry (local, notmuch,
|
|
|
|
filename, &direntry);
|
|
|
|
if (status)
|
|
|
|
return status;
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
term = talloc_asprintf (notmuch, "%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
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
for ( ; i != end; i++) {
|
|
|
|
Xapian::TermIterator j;
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
document = find_document_for_doc_id (notmuch, *i);
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
document.remove_term (term);
|
2009-12-22 00:14:32 +01:00
|
|
|
|
2010-04-24 16:22:34 +02:00
|
|
|
j = document.termlist_begin ();
|
|
|
|
j.skip_to (prefix);
|
|
|
|
|
|
|
|
/* Was this the last file-direntry in the message? */
|
|
|
|
if (j == document.termlist_end () ||
|
|
|
|
strncmp ((*j).c_str (), prefix, strlen (prefix)))
|
|
|
|
{
|
|
|
|
db->delete_document (document.get_docid ());
|
|
|
|
status = NOTMUCH_STATUS_SUCCESS;
|
|
|
|
} else {
|
|
|
|
db->replace_document (document.get_docid (), document);
|
|
|
|
status = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
|
|
|
|
}
|
2009-12-22 00:14:32 +01:00
|
|
|
}
|
2010-04-24 16:22:34 +02:00
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
fprintf (stderr, "Error: A Xapian exception occurred removing message: %s\n",
|
|
|
|
error.get_msg().c_str());
|
|
|
|
notmuch->exception_reported = TRUE;
|
|
|
|
status = NOTMUCH_STATUS_XAPIAN_EXCEPTION;
|
2009-12-22 00:14:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
talloc_free (local);
|
|
|
|
|
2010-01-06 19:06:00 +01:00
|
|
|
return status;
|
2009-12-22 00:14:32 +01:00
|
|
|
}
|
|
|
|
|
2009-11-23 01:10:54 +01:00
|
|
|
notmuch_tags_t *
|
|
|
|
_notmuch_convert_tags (void *ctx, Xapian::TermIterator &i,
|
|
|
|
Xapian::TermIterator &end)
|
|
|
|
{
|
|
|
|
const char *prefix = _find_prefix ("tag");
|
|
|
|
notmuch_tags_t *tags;
|
|
|
|
std::string tag;
|
|
|
|
|
|
|
|
/* Currently this iteration is written with the assumption that
|
|
|
|
* "tag" has a single-character prefix. */
|
|
|
|
assert (strlen (prefix) == 1);
|
|
|
|
|
|
|
|
tags = _notmuch_tags_create (ctx);
|
|
|
|
if (unlikely (tags == NULL))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
i.skip_to (prefix);
|
|
|
|
|
|
|
|
while (i != end) {
|
|
|
|
tag = *i;
|
|
|
|
|
|
|
|
if (tag.empty () || tag[0] != *prefix)
|
|
|
|
break;
|
|
|
|
|
|
|
|
_notmuch_tags_add_tag (tags, tag.c_str () + 1);
|
|
|
|
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
|
|
|
|
_notmuch_tags_prepare_iterator (tags);
|
|
|
|
|
|
|
|
return tags;
|
|
|
|
}
|
|
|
|
|
|
|
|
notmuch_tags_t *
|
|
|
|
notmuch_database_get_all_tags (notmuch_database_t *db)
|
|
|
|
{
|
|
|
|
Xapian::TermIterator i, end;
|
2010-04-24 16:22:34 +02:00
|
|
|
|
|
|
|
try {
|
|
|
|
i = db->xapian_db->allterms_begin();
|
|
|
|
end = db->xapian_db->allterms_end();
|
|
|
|
return _notmuch_convert_tags(db, i, end);
|
|
|
|
} catch (const Xapian::Error &error) {
|
|
|
|
fprintf (stderr, "A Xapian exception occurred getting tags: %s.\n",
|
|
|
|
error.get_msg().c_str());
|
|
|
|
db->exception_reported = TRUE;
|
|
|
|
return NULL;
|
|
|
|
}
|
2009-11-23 01:10:54 +01:00
|
|
|
}
|