/* Here's the current schema for our database (for NOTMUCH_DATABASE_VERSION):
*
- * We currently have two different types of documents: mail and directory.
+ * We currently have two different types of documents (mail and
+ * directory) and also some metadata.
*
* Mail document
* -------------
*
* The data portion of a directory document contains the path of the
* directory (relative to the database path).
+ *
+ * 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
+ * family of metadata name. Any particular name
+ * is formed by concatenating "thread_id_" with a
+ * message ID. The value stored is a thread ID.
+ *
+ * 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.
*/
/* With these prefix values we follow the conventions published here:
const char *message_id)
{
notmuch_message_t *message;
- const char *ret = NULL;
+ string thread_id_string;
+ const char *thread_id;
+ char *metadata_key;
+ Xapian::WritableDatabase *db;
message = notmuch_database_find_message (notmuch, message_id);
- /* If we haven't seen that message yet then check if we have already
- * generated a dummy id for it and stored it in the metadata.
- * If not then we generate a new thread id.
- * This ensures that we can thread messages even when we haven't received
- * the root (yet?)
- */
- if (message == NULL) {
- Xapian::WritableDatabase *db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
- char * metadata_key = _get_metadata_thread_id_key (ctx, message_id);
- string thread_id = notmuch->xapian_db->get_metadata(metadata_key);
- if (thread_id.empty()) {
- ret = _notmuch_database_generate_thread_id(notmuch);
- db->set_metadata(metadata_key, ret);
- } else {
- ret = thread_id.c_str();
- }
- talloc_free (metadata_key);
- goto DONE;
- }
- ret = talloc_steal (ctx, notmuch_message_get_thread_id (message));
+ if (message) {
+ thread_id = talloc_steal (ctx, notmuch_message_get_thread_id (message));
- DONE:
- if (message)
notmuch_message_destroy (message);
- return ret;
+ 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;
}
static notmuch_status_t
const char *parent_thread_id;
parent_message_id = (char *) l->data;
+
+ _notmuch_message_add_term (message, "reference",
+ parent_message_id);
+
parent_thread_id = _resolve_message_id_to_thread_id (notmuch,
message,
parent_message_id);
- if (parent_thread_id == NULL) {
- _notmuch_message_add_term (message, "reference",
- parent_message_id);
- } else {
- 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;
- }
+ 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;
}
}
/* Given a (mostly empty) 'message' and its corresponding
* 'message_file' link it to existing threads in the database.
*
- * We first look at 'message_file' and its link-relevant headers
- * (References and In-Reply-To) for message IDs. We also look in the
- * database for existing message that reference 'message'. In either
- * case, we will assign to the current message the first thread_id
+ * 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
* 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).
*
- * Finally, if not thread ID has been found through parent or child,
- * we call _notmuch_message_generate_thread_id to generate a new
- * generates a new thread ID if the message doesn't connect to any
- * existing threads.
+ * 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).
*/
static notmuch_status_t
_notmuch_database_link_message (notmuch_database_t *notmuch,
notmuch_message_file_t *message_file)
{
notmuch_status_t status;
- const char *thread_id = NULL;
- char *metadata_key = _get_metadata_thread_id_key (message,
- notmuch_message_get_message_id (message));
+ 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);
+
/* 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.
*/
- string stored_id = notmuch->xapian_db->get_metadata (metadata_key);
- if (!stored_id.empty()) {
- Xapian::WritableDatabase *db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
+ 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. */
db->set_metadata (metadata_key, "");
thread_id = stored_id.c_str();
+
_notmuch_message_add_term (message, "thread", thread_id);
}
talloc_free (metadata_key);
projects / notmuch / blobdiff