[PATCH 0/14] Implement and use database "features"

[PATCH 0/14] Implement and use database "features"

[Austin Clements]

This series is not as long as it looks!  Patch 5 is the only one
that's even slightly lengthy and almost any prefix of the series can
be sensibly reviewed and pushed on its own.

This series implements support for database features as described in
my earlier proposal [1].  This should simplify future database schema
changes and upgrades, enabling us to iterate faster on notmuch's core.
It also substantially improves forward and backwards compatibility and
improves user error reporting related to compatibility.  Patches 9 and
on make use of database features throughout the rest of libnotmuch to
simplify and improve code, improve performance, and even make the
libnotmuch interface safer and easier to use correctly.

Once features support has been merged, it should be easy to implement
various pending changes, including ghost messages [2] (I have this
mostly implemented already) and ctimes [3].

[1] id:87sim8ob48.fsf@awakening.csail.mit.edu
[2] id:20140421162058.GE25817@mit.edu
[3] id:87wqexnqvb.fsf@ta.scs.stanford.edu

[PATCH 01/14] test: Include generated dependencies for test sources

[Austin Clements]

Previously the build system was generating automatic header
dependencies for test sources, but only smtp-dummy was in SRCS, so
only its dependencies were being included.  Add all of the test
sources to SRCS so that the root Makefile.local includes their
dependencies.
---
 test/Makefile.local | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/test/Makefile.local b/test/Makefile.local
index 1c85b18..916dd0b 100644
--- a/test/Makefile.local
+++ b/test/Makefile.local
@@ -37,12 +37,17 @@ $(dir)/parse-time: $(dir)/parse-time.o parse-time-string/parse-time-string.o
 
 .PHONY: test check
 
-TEST_BINARIES=$(dir)/arg-test \
-	      $(dir)/hex-xcode \
-	      $(dir)/random-corpus \
-	      $(dir)/parse-time \
-	      $(dir)/smtp-dummy \
-	      $(dir)/symbol-test
+test_main_srcs=$(dir)/arg-test.c \
+	      $(dir)/hex-xcode.c \
+	      $(dir)/random-corpus.c \
+	      $(dir)/parse-time.c \
+	      $(dir)/smtp-dummy.c \
+	      $(dir)/symbol-test.cc \
+
+test_srcs=$(test_main_srcs) $(dir)/database-test.c
+
+TEST_BINARIES := $(test_main_srcs:.c=)
+TEST_BINARIES := $(TEST_BINARIES:.cc=)
 
 test-binaries: $(TEST_BINARIES)
 
@@ -51,7 +56,7 @@ test:	all test-binaries
 
 check: test
 
-SRCS := $(SRCS) $(smtp_dummy_srcs)
+SRCS := $(SRCS) $(test_srcs)
 CLEAN += $(TEST_BINARIES) $(addsuffix .o,$(TEST_BINARIES)) \
 	 $(dir)/database-test.o \
 	 $(dir)/corpus.mail $(dir)/test-results $(dir)/tmp.*
-- 
2.0.0

[PATCH 02/14] util: Make string-util.h C++-compatible

[Austin Clements]

---
 util/string-util.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/util/string-util.h b/util/string-util.h
index 8a3ad19..ccad17f 100644
--- a/util/string-util.h
+++ b/util/string-util.h
@@ -3,6 +3,10 @@
 
 #include <string.h>
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 /* like strtok(3), but without state, and doesn't modify s.  Return
  * value is indicated by pointer and length, not null terminator.
  *
@@ -57,4 +61,8 @@ int
 parse_boolean_term (void *ctx, const char *str,
 		    char **prefix_out, char **term_out);
 
+#ifdef __cplusplus
+}
+#endif
+
 #endif
-- 
2.0.0

[PATCH 03/14] util: Const version of strtok_len

[Austin Clements]

Because of limitations in the C type system, we can't a strtok_len
that can work on both const string and non-const strings.  The C
library solves this by taking a const char* and returning a char*
in functions like this (e.g., strchr), but that's not const-safe.
Solve it by introducing strtok_len_c, a version of strtok_len for
const strings.
---
 util/string-util.c | 8 ++++++++
 util/string-util.h | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/util/string-util.c b/util/string-util.c
index 3e7066c..a90501e 100644
--- a/util/string-util.c
+++ b/util/string-util.c
@@ -37,6 +37,14 @@ strtok_len (char *s, const char *delim, size_t *len)
     return *len ? s : NULL;
 }
 
+const char *
+strtok_len_c (const char *s, const char *delim, size_t *len)
+{
+    /* strtok_len is already const-safe, but we can't express both
+     * versions in the C type system. */
+    return strtok_len ((char*)s, delim, len);
+}
+
 char *
 sanitize_string (const void *ctx, const char *str)
 {
diff --git a/util/string-util.h b/util/string-util.h
index ccad17f..e409cb3 100644
--- a/util/string-util.h
+++ b/util/string-util.h
@@ -23,6 +23,9 @@ extern "C" {
 
 char *strtok_len (char *s, const char *delim, size_t *len);
 
+/* Const version of strtok_len. */
+const char *strtok_len_c (const char *s, const char *delim, size_t *len);
+
 /* Return a talloced string with str sanitized.
  *
  * Whitespace characters (tabs and newlines) are replaced with spaces,
-- 
2.0.0

[PATCH 04/14] new: Don't report version after upgrade

[Austin Clements]

The version number has always been pretty meaningless to the user and
it's about to become even more meaningless with the introduction of
"features".  Hopefully, the database will remain on version 3 for some
time to come; however, the introduction of new features over time in
version 3 will necessitate upgrades within version 3.  It would be
confusing if we always tell the user they've been "upgraded to version
3".  If the user wants to know what's new, they should read the news.
---
 notmuch-new.c        | 3 +--
 test/T530-upgrade.sh | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index d269c7c..b7590a8 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -1023,8 +1023,7 @@ notmuch_new_command (notmuch_config_t *config, int argc, char *argv[])
 				      add_files_state.verbosity >= VERBOSITY_NORMAL ? upgrade_print_progress : NULL,
 				      &add_files_state);
 	    if (add_files_state.verbosity >= VERBOSITY_NORMAL)
-		printf ("Your notmuch database has now been upgraded to database format version %u.\n",
-		    notmuch_database_get_version (notmuch));
+		printf ("Your notmuch database has now been upgraded.\n");
 	}
 
 	add_files_state.total_files = 0;
diff --git a/test/T530-upgrade.sh b/test/T530-upgrade.sh
index 7d5d5aa..c4c4ac8 100755
--- a/test/T530-upgrade.sh
+++ b/test/T530-upgrade.sh
@@ -33,7 +33,7 @@ test_expect_equal "$output" "\
 Welcome to a new version of notmuch! Your database will now be upgraded.
 This process is safe to interrupt.
 Backing up tags to FILENAME
-Your notmuch database has now been upgraded to database format version 2.
+Your notmuch database has now been upgraded.
 No new mail."
 
 test_begin_subtest "tag backup matches pre-upgrade dump"
-- 
2.0.0

[PATCH 05/14] lib: Database version 3: Introduce fine-grained "features"

[Austin Clements]

Previously, our database schema was versioned by a single number.
Each database schema change had to occur "atomically" in Notmuch's
development history: before some commit, Notmuch used version N, after
that commit, it used version N+1.  Hence, each new schema version
could introduce only one change, the task of developing a schema
change fell on a single person, and it all had to happen and be
perfect in a single commit series.  This made introducing a new schema
version hard.  We've seen only two schema changes in the history of
Notmuch.

This commit introduces database schema version 3; hopefully the last
schema version we'll need for a while.  With this version, we switch
from a single version number to "features": a set of named,
independent aspects of the database schema.

Features should make backwards compatibility easier.  For many things,
it should be easy to support databases both with and without a
feature, which will allow us to make upgrades optional and will enable
"unstable" features that can be developed and tested over time.

Features also make forwards compatibility easier.  The features
recorded in a database include "compatibility flags," which can
indicate to an older version of Notmuch when it must support a given
feature to open the database for read or for write.  This lets us
replace the old vague "I don't recognize this version, so something
might go wrong, but I promise to try my best" warnings upon opening a
database with an unknown version with precise errors.  If a database
is safe to open for read/write despite unknown features, an older
version will know that and issue no message at all.  If the database
is not safe to open for read/write because of unknown features, an
older version will know that, too, and can tell the user exactly which
required features it lacks support for.
---
 lib/database-private.h |  56 +++++++++++++++
 lib/database.cc        | 189 +++++++++++++++++++++++++++++++++++++++++--------
 2 files changed, 214 insertions(+), 31 deletions(-)

diff --git a/lib/database-private.h b/lib/database-private.h
index d3e65fd..323b9fe 100644
--- a/lib/database-private.h
+++ b/lib/database-private.h
@@ -46,6 +46,11 @@ struct _notmuch_database {
     int atomic_nesting;
     Xapian::Database *xapian_db;
 
+    /* Bit mask of features used by this database.  Features are
+     * named, independent aspects of the database schema.  This is a
+     * bitwise-OR of NOTMUCH_FEATURE_* values (below). */
+    unsigned int features;
+
     unsigned int last_doc_id;
     uint64_t last_thread_id;
 
@@ -55,6 +60,57 @@ struct _notmuch_database {
     Xapian::ValueRangeProcessor *date_range_processor;
 };
 
+/* Bit masks for _notmuch_database::features. */
+enum {
+    /* If set, file names are stored in "file-direntry" terms.  If
+     * unset, file names are stored in document data.
+     *
+     * Introduced: version 1.  Implementation support: both for read;
+     * required for write. */
+    NOTMUCH_FEATURE_FILE_TERMS = 1 << 0,
+
+    /* If set, directory timestamps are stored in documents with
+     * XDIRECTORY terms and relative paths.  If unset, directory
+     * timestamps are stored in documents with XTIMESTAMP terms and
+     * absolute paths.
+     *
+     * Introduced: version 1.  Implementation support: required. */
+    NOTMUCH_FEATURE_DIRECTORY_DOCS = 1 << 1,
+
+    /* If set, the from, subject, and message-id headers are stored in
+     * message document values.  If unset, message documents *may*
+     * have these values, but if the value is empty, it must be
+     * retrieved from the message file.
+     *
+     * Introduced: optional in version 1, required as of version 3.
+     * Implementation support: both.
+     */
+    NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES = 1 << 2,
+
+    /* If set, folder terms are boolean and path terms exist.  If
+     * unset, folder terms are probabilistic and stemmed and path
+     * terms do not exist.
+     *
+     * Introduced: version 2.  Implementation support: required. */
+    NOTMUCH_FEATURE_BOOL_FOLDER = 1 << 3,
+};
+
+/* Prior to database version 3, features were implied by the database
+ * version number, so hard-code them for earlier versions. */
+#define NOTMUCH_FEATURES_V0 (0)
+#define NOTMUCH_FEATURES_V1 (NOTMUCH_FEATURES_V0 | NOTMUCH_FEATURE_FILE_TERMS | \
+			     NOTMUCH_FEATURE_DIRECTORY_DOCS)
+#define NOTMUCH_FEATURES_V2 (NOTMUCH_FEATURES_V1 | NOTMUCH_FEATURE_BOOL_FOLDER)
+
+/* Current database features.  If any of these are missing from a
+ * database, request an upgrade.
+ * NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES is not included because
+ * upgrade doesn't currently introduce the feature (though brand new
+ * databases will have it). */
+#define NOTMUCH_FEATURES_CURRENT \
+    (NOTMUCH_FEATURE_FILE_TERMS | NOTMUCH_FEATURE_DIRECTORY_DOCS | \
+     NOTMUCH_FEATURE_BOOL_FOLDER)
+
 /* Return the list of terms from the given iterator matching a prefix.
  * The prefix will be stripped from the strings in the returned list.
  * The list will be allocated using ctx as the talloc context.
diff --git a/lib/database.cc b/lib/database.cc
index 45c4260..03eef3e 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -20,6 +20,7 @@
 
 #include "database-private.h"
 #include "parse-time-vrp.h"
+#include "string-util.h"
 
 #include <iostream>
 
@@ -42,7 +43,7 @@ typedef struct {
     const char *prefix;
 } prefix_t;
 
-#define NOTMUCH_DATABASE_VERSION 2
+#define NOTMUCH_DATABASE_VERSION 3
 
 #define STRINGIFY(s) _SUB_STRINGIFY(s)
 #define _SUB_STRINGIFY(s) #s
@@ -151,6 +152,17 @@ typedef struct {
  *			changes are made to the database (such as by
  *			indexing new fields).
  *
+ *	features	The set of features supported by this
+ *			database. This consists of a set of
+ *			'\n'-separated lines, where each is a feature
+ *			name, a '\t', and compatibility flags.  If the
+ *			compatibility flags contain 'w', then the
+ *			opener must support this feature to safely
+ *			write this database.  If the compatibility
+ *			flags contain 'r', then the opener must
+ *			support this feature to read this database.
+ *			Introduced in database version 3.
+ *
  *	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
@@ -226,6 +238,7 @@ static prefix_t PROBABILISTIC_PREFIX[]= {
     { "subject",		"XSUBJECT"},
 };
 
+
 const char *
 _find_prefix (const char *name)
 {
@@ -251,6 +264,25 @@ _find_prefix (const char *name)
     return "";
 }
 
+static const struct
+{
+    /* NOTMUCH_FEATURE_* value. */
+    unsigned int value;
+    /* Feature name as it appears in the database.  This name should
+     * be appropriate for displaying to the user if an older version
+     * of notmuch doesn't support this feature. */
+    const char *name;
+    /* Compatibility flags when this feature is declared. */
+    const char *flags;
+} feature_names[] = {
+    {NOTMUCH_FEATURE_FILE_TERMS,             "file terms", "rw"},
+    {NOTMUCH_FEATURE_DIRECTORY_DOCS,         "directory documents", "rw"},
+    /* Header values are not required for reading a database because a
+     * reader can just refer to the message file. */
+    {NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES, "from/subject/ID values", "w"},
+    {NOTMUCH_FEATURE_BOOL_FOLDER,            "boolean folder terms", "rw"},
+};
+
 const char *
 notmuch_status_to_string (notmuch_status_t status)
 {
@@ -591,6 +623,11 @@ notmuch_database_create (const char *path, notmuch_database_t **database)
 				    &notmuch);
     if (status)
 	goto DONE;
+
+    /* Upgrade doesn't add this feature to existing databases, but new
+     * databases have it. */
+    notmuch->features |= NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES;
+
     status = notmuch_database_upgrade (notmuch, NULL, NULL);
     if (status) {
 	notmuch_database_close(notmuch);
@@ -619,6 +656,80 @@ _notmuch_database_ensure_writable (notmuch_database_t *notmuch)
     return NOTMUCH_STATUS_SUCCESS;
 }
 
+/* Parse a database features string from the given database version.
+ *
+ * For version < 3, this ignores the features string and returns a
+ * hard-coded set of features.
+ *
+ * If there are unrecognized features that are required to open the
+ * database in mode (which should be 'r' or 'w'), return a
+ * comma-separated list of unrecognized but required features in
+ * *incompat_out, which will be allocated from ctx.
+ */
+static unsigned int
+_parse_features (const void *ctx, const char *features, unsigned int version,
+		 char mode, char **incompat_out)
+{
+    unsigned int res = 0, namelen, i;
+    size_t llen = 0;
+    const char *flags;
+
+    /* Prior to database version 3, features were implied by the
+     * version number. */
+    if (version == 0)
+	return NOTMUCH_FEATURES_V0;
+    else if (version == 1)
+	return NOTMUCH_FEATURES_V1;
+    else if (version == 2)
+	return NOTMUCH_FEATURES_V2;
+
+    /* Parse the features string */
+    while ((features = strtok_len_c (features + llen, "\n", &llen)) != NULL) {
+	flags = strchr (features, '\t');
+	if (! flags || flags > features + llen)
+	    continue;
+	namelen = flags - features;
+
+	for (i = 0; i < ARRAY_SIZE (feature_names); ++i) {
+	    if (strlen (feature_names[i].name) == namelen &&
+		strncmp (feature_names[i].name, features, namelen) == 0) {
+		res |= feature_names[i].value;
+		break;
+	    }
+	}
+
+	if (i == ARRAY_SIZE (feature_names)) {
+	    /* Unrecognized feature */
+	    const char *have = strchr (flags, mode);
+	    if (have && have < features + llen) {
+		/* This feature is required to access this database in
+		 * 'mode', but we don't understand it. */
+		if (! *incompat_out)
+		    *incompat_out = talloc_strdup (ctx, "");
+		*incompat_out = talloc_asprintf_append_buffer (
+		    *incompat_out, "%s%.*s", **incompat_out ? ", " : "",
+		    namelen, features);
+	    }
+	}
+    }
+
+    return res;
+}
+
+static char *
+_print_features (const void *ctx, unsigned int features)
+{
+    unsigned int i;
+    char *res = talloc_strdup (ctx, "");
+
+    for (i = 0; i < ARRAY_SIZE (feature_names); ++i)
+	if (features & feature_names[i].value)
+	    res = talloc_asprintf_append_buffer (
+		res, "%s\t%s\n", feature_names[i].name, feature_names[i].flags);
+
+    return res;
+}
+
 notmuch_status_t
 notmuch_database_open (const char *path,
 		       notmuch_database_mode_t mode,
@@ -627,7 +738,7 @@ notmuch_database_open (const char *path,
     notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
     void *local = talloc_new (NULL);
     notmuch_database_t *notmuch = NULL;
-    char *notmuch_path, *xapian_path;
+    char *notmuch_path, *xapian_path, *incompat_features;
     struct stat st;
     int err;
     unsigned int i, version;
@@ -686,39 +797,51 @@ notmuch_database_open (const char *path,
 	if (mode == NOTMUCH_DATABASE_MODE_READ_WRITE) {
 	    notmuch->xapian_db = new Xapian::WritableDatabase (xapian_path,
 							       Xapian::DB_CREATE_OR_OPEN);
-	    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_destroy (notmuch);
-		notmuch = NULL;
-		status = NOTMUCH_STATUS_FILE_ERROR;
-		goto DONE;
-	    }
-
-	    if (version < NOTMUCH_DATABASE_VERSION)
-		notmuch->needs_upgrade = TRUE;
 	} else {
 	    notmuch->xapian_db = new Xapian::Database (xapian_path);
-	    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);
-	    }
 	}
 
+	/* Check version.  As of database version 3, we represent
+	 * changes in terms of features, so assume a version bump
+	 * means a dramatically incompatible change. */
+	version = notmuch_database_get_version (notmuch);
+	if (version > NOTMUCH_DATABASE_VERSION) {
+	    fprintf (stderr,
+		     "Error: Notmuch database at %s\n"
+		     "       has a newer database format version (%u) than supported by this\n"
+		     "       version of notmuch (%u).\n",
+		     notmuch_path, version, NOTMUCH_DATABASE_VERSION);
+	    notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
+	    notmuch_database_destroy (notmuch);
+	    notmuch = NULL;
+	    status = NOTMUCH_STATUS_FILE_ERROR;
+	    goto DONE;
+	}
+
+	/* Check features. */
+	incompat_features = NULL;
+	notmuch->features = _parse_features (
+	    local, notmuch->xapian_db->get_metadata ("features").c_str (),
+	    version, mode == NOTMUCH_DATABASE_MODE_READ_WRITE ? 'w' : 'r',
+	    &incompat_features);
+	if (incompat_features) {
+	    fprintf (stderr,
+		     "Error: Notmuch database at %s\n"
+		     "       requires features (%s)\n"
+		     "       not supported by this version of notmuch.\n",
+		     notmuch_path, incompat_features);
+	    notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
+	    notmuch_database_destroy (notmuch);
+	    notmuch = NULL;
+	    status = NOTMUCH_STATUS_FILE_ERROR;
+	    goto DONE;
+	}
+
+	/* Do we want an upgrade? */
+	if (mode == NOTMUCH_DATABASE_MODE_READ_WRITE &&
+	    NOTMUCH_FEATURES_CURRENT & ~notmuch->features)
+	    notmuch->needs_upgrade = TRUE;
+
 	notmuch->last_doc_id = notmuch->xapian_db->get_lastdocid ();
 	last_thread_id = notmuch->xapian_db->get_metadata ("last_thread_id");
 	if (last_thread_id.empty ()) {
@@ -1077,6 +1200,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 						   double progress),
 			  void *closure)
 {
+    void *local = talloc_new (NULL);
     Xapian::WritableDatabase *db;
     struct sigaction action;
     struct itimerval timerval;
@@ -1226,6 +1350,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	notmuch_query_destroy (query);
     }
 
+    notmuch->features |= NOTMUCH_FEATURES_CURRENT;
+    db->set_metadata ("features", _print_features (local, notmuch->features));
     db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
     db->flush ();
 
@@ -1302,6 +1428,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	sigaction (SIGALRM, &action, NULL);
     }
 
+    talloc_free (local);
     return NOTMUCH_STATUS_SUCCESS;
 }
 
-- 
2.0.0

[PATCH 06/14] test: Tool to build DB with specific version and features

[Austin Clements]

This will let us test basic version and feature handling.
---
 test/.gitignore         |  1 +
 test/Makefile.local     |  4 ++++
 test/make-db-version.cc | 35 +++++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+)
 create mode 100644 test/make-db-version.cc

diff --git a/test/.gitignore b/test/.gitignore
index b3b706d..0f7d5bf 100644
--- a/test/.gitignore
+++ b/test/.gitignore
@@ -5,5 +5,6 @@ parse-time
 random-corpus
 smtp-dummy
 symbol-test
+make-db-version
 test-results
 tmp.*
diff --git a/test/Makefile.local b/test/Makefile.local
index 916dd0b..a2d58fc 100644
--- a/test/Makefile.local
+++ b/test/Makefile.local
@@ -35,6 +35,9 @@ $(dir)/symbol-test: $(dir)/symbol-test.o lib/$(LINKER_NAME)
 $(dir)/parse-time: $(dir)/parse-time.o parse-time-string/parse-time-string.o
 	$(call quiet,CC) $^ -o $@
 
+$(dir)/make-db-version: $(dir)/make-db-version.o
+	$(call quiet,CXX) $^ -o $@ $(XAPIAN_LDFLAGS)
+
 .PHONY: test check
 
 test_main_srcs=$(dir)/arg-test.c \
@@ -43,6 +46,7 @@ test_main_srcs=$(dir)/arg-test.c \
 	      $(dir)/parse-time.c \
 	      $(dir)/smtp-dummy.c \
 	      $(dir)/symbol-test.cc \
+	      $(dir)/make-db-version.cc \
 
 test_srcs=$(test_main_srcs) $(dir)/database-test.c
 
diff --git a/test/make-db-version.cc b/test/make-db-version.cc
new file mode 100644
index 0000000..fa80cac
--- /dev/null
+++ b/test/make-db-version.cc
@@ -0,0 +1,35 @@
+/* Create an empty notmuch database with a specific version and
+ * features. */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+
+#include <xapian.h>
+
+int main(int argc, char **argv)
+{
+    if (argc != 4) {
+	fprintf (stderr, "Usage: %s mailpath version features\n", argv[0]);
+	exit (2);
+    }
+
+    std::string nmpath (argv[1]);
+    nmpath += "/.notmuch";
+    if (mkdir (nmpath.c_str (), 0777) < 0) {
+	perror (("failed to create " + nmpath).c_str ());
+	exit (1);
+    }
+
+    try {
+	Xapian::WritableDatabase db (
+	    nmpath + "/xapian", Xapian::DB_CREATE_OR_OPEN);
+	db.set_metadata ("version", argv[2]);
+	db.set_metadata ("features", argv[3]);
+	db.commit ();
+    } catch (const Xapian::Error &e) {
+	fprintf (stderr, "%s\n", e.get_description ().c_str ());
+	exit (1);
+    }
+}
-- 
2.0.0

[PATCH 07/14] test: Tests for future version and unknown feature handling

[Austin Clements]

---
 test/T530-upgrade.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/test/T530-upgrade.sh b/test/T530-upgrade.sh
index c4c4ac8..c88bbc7 100755
--- a/test/T530-upgrade.sh
+++ b/test/T530-upgrade.sh
@@ -3,6 +3,52 @@ test_description="database upgrade"
 
 . ./test-lib.sh
 
+test_begin_subtest "future database versions abort open"
+${TEST_DIRECTORY}/make-db-version ${MAIL_DIR} 9999 ""
+output=$(notmuch search x 2>&1 | sed 's/\(database at\) .*/\1 FILENAME/')
+rm -rf ${MAIL_DIR}/.notmuch
+test_expect_equal "$output" "\
+Error: Notmuch database at FILENAME
+       has a newer database format version (9999) than supported by this
+       version of notmuch (3)."
+
+test_begin_subtest "unknown 'rw' feature aborts read/write open"
+${TEST_DIRECTORY}/make-db-version ${MAIL_DIR} 3 $'test feature\trw'
+output=$(notmuch new 2>&1 | sed 's/\(database at\) .*/\1 FILENAME/')
+rm -rf ${MAIL_DIR}/.notmuch
+test_expect_equal "$output" "\
+Error: Notmuch database at FILENAME
+       requires features (test feature)
+       not supported by this version of notmuch."
+
+test_begin_subtest "unknown 'rw' feature aborts read-only open"
+${TEST_DIRECTORY}/make-db-version ${MAIL_DIR} 3 $'test feature\trw'
+output=$(notmuch search x 2>&1 | sed 's/\(database at\) .*/\1 FILENAME/')
+rm -rf ${MAIL_DIR}/.notmuch
+test_expect_equal "$output" "\
+Error: Notmuch database at FILENAME
+       requires features (test feature)
+       not supported by this version of notmuch."
+
+test_begin_subtest "unknown 'w' feature aborts read/write open"
+${TEST_DIRECTORY}/make-db-version ${MAIL_DIR} 3 $'test feature\tw'
+output=$(notmuch new 2>&1 | sed 's/\(database at\) .*/\1 FILENAME/')
+rm -rf ${MAIL_DIR}/.notmuch
+test_expect_equal "$output" "\
+Error: Notmuch database at FILENAME
+       requires features (test feature)
+       not supported by this version of notmuch."
+
+test_begin_subtest "unknown 'w' feature does not abort read-only open"
+${TEST_DIRECTORY}/make-db-version ${MAIL_DIR} 3 $'test feature\tw'
+output=$(notmuch search x 2>&1 | sed 's/\(database at\) .*/\1 FILENAME/')
+rm -rf ${MAIL_DIR}/.notmuch
+test_expect_equal "$output" ""
+
+#
+# Database v1
+#
+
 dbtarball=database-v1.tar.xz
 
 # XXX: Accomplish the same with test lib helpers
-- 
2.0.0

[PATCH 08/14] lib: Simplify upgrade code using a transaction

[Austin Clements]

Previously, the upgrade was organized as two passes -- an upgrade
pass, and a separate cleanup pass -- so the database was always in a
valid state.  This change substantially simplifies this code by
performing the upgrade in a transaction and combining both passes in
to one.  This 1) eliminates a lot of duplicate code between the
passes, 2) speeds up the upgrade process, 3) makes progress reporting
more accurate, 4) eliminates the potential for stale data if the
upgrade is interrupted during the cleanup pass, and 5) makes it easier
to reason about the safety of the upgrade code.
---
 lib/database.cc | 67 ++++++---------------------------------------------------
 1 file changed, 7 insertions(+), 60 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index 03eef3e..0be7180 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1238,6 +1238,9 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	timer_is_active = TRUE;
     }
 
+    /* Perform the upgrade in a transaction. */
+    db->begin_transaction (true);
+
     /* Before version 1, each message document had its filename in the
      * data field. Copy that into the new format by calling
      * notmuch_message_add_filename.
@@ -1265,6 +1268,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	    filename = _notmuch_message_talloc_copy_data (message);
 	    if (filename && *filename != '\0') {
 		_notmuch_message_add_filename (message, filename);
+		_notmuch_message_clear_data (message);
 		_notmuch_message_sync (message);
 	    }
 	    talloc_free (filename);
@@ -1312,6 +1316,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 						       NOTMUCH_FIND_CREATE, &status);
 		notmuch_directory_set_mtime (directory, mtime);
 		notmuch_directory_destroy (directory);
+
+		db->delete_document (*p);
 	    }
 	}
     }
@@ -1353,67 +1359,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
     notmuch->features |= NOTMUCH_FEATURES_CURRENT;
     db->set_metadata ("features", _print_features (local, notmuch->features));
     db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
-    db->flush ();
-
-    /* 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);
-	     notmuch_messages_valid (messages);
-	     notmuch_messages_move_to_next (messages))
-	{
-	    if (do_progress_notify) {
-		progress_notify (closure, (double) count / total);
-		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++)
-	    {
-		if (do_progress_notify) {
-		    progress_notify (closure, (double) count / total);
-		    do_progress_notify = 0;
-		}
-
-		db->delete_document (*p);
-	    }
-	}
-    }
+    db->commit_transaction ();
 
     if (timer_is_active) {
 	/* Now stop the timer. */
-- 
2.0.0

[PATCH 09/14] lib: Use database features to drive upgrade

[Austin Clements]

Previously, we had database version information hard-coded in the
upgrade code.  Slightly re-organize the upgrade process around the set
of new database features to be enabled by the upgrade.
---
 lib/database.cc | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index 0be7180..1dd2cd9 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1201,11 +1201,12 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 			  void *closure)
 {
     void *local = talloc_new (NULL);
+    Xapian::TermIterator t, t_end;
     Xapian::WritableDatabase *db;
     struct sigaction action;
     struct itimerval timerval;
     notmuch_bool_t timer_is_active = FALSE;
-    unsigned int version;
+    unsigned int target_features, new_features;
     notmuch_status_t status;
     unsigned int count = 0, total = 0;
 
@@ -1215,9 +1216,10 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 
     db = static_cast <Xapian::WritableDatabase *> (notmuch->xapian_db);
 
-    version = notmuch_database_get_version (notmuch);
+    target_features = notmuch->features | NOTMUCH_FEATURES_CURRENT;
+    new_features = NOTMUCH_FEATURES_CURRENT & ~notmuch->features;
 
-    if (version >= NOTMUCH_DATABASE_VERSION)
+    if (! new_features)
 	return NOTMUCH_STATUS_SUCCESS;
 
     if (progress_notify) {
@@ -1245,12 +1247,11 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
      * data field. Copy that into the new format by calling
      * notmuch_message_add_filename.
      */
-    if (version < 1) {
+    if (new_features & NOTMUCH_FEATURE_FILE_TERMS) {
 	notmuch_query_t *query = notmuch_query_create (notmuch, "");
 	notmuch_messages_t *messages;
 	notmuch_message_t *message;
 	char *filename;
-	Xapian::TermIterator t, t_end;
 
 	total = notmuch_query_count_messages (query);
 
@@ -1279,11 +1280,12 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	}
 
 	notmuch_query_destroy (query);
+    }
 
-	/* Also, before version 1 we stored directory timestamps in
-	 * XTIMESTAMP documents instead of the current XDIRECTORY
-	 * documents. So copy those as well. */
-
+    /* Also, before version 1 we stored directory timestamps in
+     * XTIMESTAMP documents instead of the current XDIRECTORY
+     * documents. So copy those as well. */
+    if (new_features & NOTMUCH_FEATURE_DIRECTORY_DOCS) {
 	t_end = notmuch->xapian_db->allterms_end ("XTIMESTAMP");
 
 	for (t = notmuch->xapian_db->allterms_begin ("XTIMESTAMP");
@@ -1327,7 +1329,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
      * stemmed. Change it to the current boolean prefix. Add "path:"
      * prefixes while at it.
      */
-    if (version < 2) {
+    if (new_features & NOTMUCH_FEATURE_BOOL_FOLDER) {
 	notmuch_query_t *query = notmuch_query_create (notmuch, "");
 	notmuch_messages_t *messages;
 	notmuch_message_t *message;
@@ -1356,7 +1358,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	notmuch_query_destroy (query);
     }
 
-    notmuch->features |= NOTMUCH_FEATURES_CURRENT;
+    notmuch->features = target_features;
     db->set_metadata ("features", _print_features (local, notmuch->features));
     db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
 
-- 
2.0.0

[PATCH 10/14] lib: Reorganize upgrade around document types

[Austin Clements]

Rather than potentially making multiple passes over the same type of
data in the database, reorganize upgrade around each type of data that
may be upgraded.  This eliminates code duplication, will make
multi-version upgrades faster, and will let us improve progress
reporting.
---
 lib/database.cc | 71 +++++++++++++++++++++------------------------------------
 1 file changed, 26 insertions(+), 45 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index 1dd2cd9..155cbac 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1243,11 +1243,9 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
     /* Perform the upgrade in a transaction. */
     db->begin_transaction (true);
 
-    /* Before version 1, each message document had its filename in the
-     * data field. Copy that into the new format by calling
-     * notmuch_message_add_filename.
-     */
-    if (new_features & NOTMUCH_FEATURE_FILE_TERMS) {
+    /* Perform per-message upgrades. */
+    if (new_features &
+	(NOTMUCH_FEATURE_FILE_TERMS | NOTMUCH_FEATURE_BOOL_FOLDER)) {
 	notmuch_query_t *query = notmuch_query_create (notmuch, "");
 	notmuch_messages_t *messages;
 	notmuch_message_t *message;
@@ -1266,13 +1264,28 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 
 	    message = notmuch_messages_get (messages);
 
-	    filename = _notmuch_message_talloc_copy_data (message);
-	    if (filename && *filename != '\0') {
-		_notmuch_message_add_filename (message, filename);
-		_notmuch_message_clear_data (message);
+	    /* Before version 1, each message document had its
+	     * filename in the data field. Copy that into the new
+	     * format by calling notmuch_message_add_filename.
+	     */
+	    if (new_features & NOTMUCH_FEATURE_FILE_TERMS) {
+		filename = _notmuch_message_talloc_copy_data (message);
+		if (filename && *filename != '\0') {
+		    _notmuch_message_add_filename (message, filename);
+		    _notmuch_message_clear_data (message);
+		    _notmuch_message_sync (message);
+		}
+		talloc_free (filename);
+	    }
+
+	    /* Prior to version 2, the "folder:" prefix was
+	     * probabilistic and stemmed. Change it to the current
+	     * boolean prefix. Add "path:" prefixes while at it.
+	     */
+	    if (new_features & NOTMUCH_FEATURE_BOOL_FOLDER) {
+		_notmuch_message_upgrade_folder (message);
 		_notmuch_message_sync (message);
 	    }
-	    talloc_free (filename);
 
 	    notmuch_message_destroy (message);
 
@@ -1282,7 +1295,9 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	notmuch_query_destroy (query);
     }
 
-    /* Also, before version 1 we stored directory timestamps in
+    /* Perform per-directory upgrades. */
+
+    /* Before version 1 we stored directory timestamps in
      * XTIMESTAMP documents instead of the current XDIRECTORY
      * documents. So copy those as well. */
     if (new_features & NOTMUCH_FEATURE_DIRECTORY_DOCS) {
@@ -1324,40 +1339,6 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	}
     }
 
-    /*
-     * Prior to version 2, the "folder:" prefix was probabilistic and
-     * stemmed. Change it to the current boolean prefix. Add "path:"
-     * prefixes while at it.
-     */
-    if (new_features & NOTMUCH_FEATURE_BOOL_FOLDER) {
-	notmuch_query_t *query = notmuch_query_create (notmuch, "");
-	notmuch_messages_t *messages;
-	notmuch_message_t *message;
-
-	count = 0;
-	total = notmuch_query_count_messages (query);
-
-	for (messages = notmuch_query_search_messages (query);
-	     notmuch_messages_valid (messages);
-	     notmuch_messages_move_to_next (messages)) {
-	    if (do_progress_notify) {
-		progress_notify (closure, (double) count / total);
-		do_progress_notify = 0;
-	    }
-
-	    message = notmuch_messages_get (messages);
-
-	    _notmuch_message_upgrade_folder (message);
-	    _notmuch_message_sync (message);
-
-	    notmuch_message_destroy (message);
-
-	    count++;
-	}
-
-	notmuch_query_destroy (query);
-    }
-
     notmuch->features = target_features;
     db->set_metadata ("features", _print_features (local, notmuch->features));
     db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
-- 
2.0.0

[PATCH 11/14] lib: Report progress for combined upgrade operation

[Austin Clements]

Previously, some parts of upgrade didn't report progress and for
others it was possible for the progress meter to restart at 0 part way
through the upgrade because each stage was reported separately.

Fix this by computing the total amount of work that needs to be done
up-front and updating completed work monotonically.
---
 lib/database.cc | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index 155cbac..a93281c 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -1240,6 +1240,19 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	timer_is_active = TRUE;
     }
 
+    /* Figure out how much total work we need to do. */
+    if (new_features &
+	(NOTMUCH_FEATURE_FILE_TERMS | NOTMUCH_FEATURE_BOOL_FOLDER)) {
+	notmuch_query_t *query = notmuch_query_create (notmuch, "");
+	total += notmuch_query_count_messages (query);
+	notmuch_query_destroy (query);
+    }
+    if (new_features & NOTMUCH_FEATURE_DIRECTORY_DOCS) {
+	t_end = db->allterms_end ("XTIMESTAMP");
+	for (t = db->allterms_begin ("XTIMESTAMP"); t != t_end; t++)
+	    ++total;
+    }
+
     /* Perform the upgrade in a transaction. */
     db->begin_transaction (true);
 
@@ -1251,8 +1264,6 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 	notmuch_message_t *message;
 	char *filename;
 
-	total = notmuch_query_count_messages (query);
-
 	for (messages = notmuch_query_search_messages (query);
 	     notmuch_messages_valid (messages);
 	     notmuch_messages_move_to_next (messages))
@@ -1336,6 +1347,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
 
 		db->delete_document (*p);
 	    }
+
+	    ++count;
 	}
     }
 
-- 
2.0.0

[PATCH 12/14] lib: Support empty header values in database

[Austin Clements]

Commit 567bcbc2 introduced support for storing various headers in
document values.  However, doing so in a backwards-compatible way
meant that genuinely empty header values could not be distinguished
from the old behavior of not storing the headers at all, so these
required parsing the original message.

Now that we have database features, new databases can declare that all
messages have header values, so if we have this feature flag, we can
use the stored header value even if it's the empty string.

This requires slight cleanup to notmuch_message_get_header, since the
code previously couldn't distinguish between empty headers and headers
that are never stored in the database (previously this distinction
didn't matter).
---
 lib/message.cc | 45 +++++++++++++++++++++++++++------------------
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/lib/message.cc b/lib/message.cc
index e6a5a5a..4fc427f 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -412,26 +412,35 @@ _notmuch_message_ensure_message_file (notmuch_message_t *message)
 const char *
 notmuch_message_get_header (notmuch_message_t *message, const char *header)
 {
-    try {
-	    std::string value;
-
-	    /* Fetch header from the appropriate xapian value field if
-	     * available */
-	    if (strcasecmp (header, "from") == 0)
-		value = message->doc.get_value (NOTMUCH_VALUE_FROM);
-	    else if (strcasecmp (header, "subject") == 0)
-		value = message->doc.get_value (NOTMUCH_VALUE_SUBJECT);
-	    else if (strcasecmp (header, "message-id") == 0)
-		value = message->doc.get_value (NOTMUCH_VALUE_MESSAGE_ID);
-
-	    if (!value.empty())
+    Xapian::valueno slot = Xapian::BAD_VALUENO;
+
+    /* Fetch header from the appropriate xapian value field if
+     * available */
+    if (strcasecmp (header, "from") == 0)
+	slot = NOTMUCH_VALUE_FROM;
+    else if (strcasecmp (header, "subject") == 0)
+	slot = NOTMUCH_VALUE_SUBJECT;
+    else if (strcasecmp (header, "message-id") == 0)
+	slot = NOTMUCH_VALUE_MESSAGE_ID;
+
+    if (slot != Xapian::BAD_VALUENO) {
+	try {
+	    std::string value = message->doc.get_value (slot);
+
+	    /* If we have NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES, then
+	     * empty values indicate empty headers.  If we don't, then
+	     * it could just mean we didn't record the header. */
+	    if ((message->notmuch->features &
+		 NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES) ||
+		! value.empty())
 		return talloc_strdup (message, value.c_str ());
 
-    } catch (Xapian::Error &error) {
-	fprintf (stderr, "A Xapian exception occurred when reading header: %s\n",
-		 error.get_msg().c_str());
-	message->notmuch->exception_reported = TRUE;
-	return NULL;
+	} catch (Xapian::Error &error) {
+	    fprintf (stderr, "A Xapian exception occurred when reading header: %s\n",
+		     error.get_msg().c_str());
+	    message->notmuch->exception_reported = TRUE;
+	    return NULL;
+	}
     }
 
     /* Otherwise fall back to parsing the file */
-- 
2.0.0

[PATCH 13/14] lib: Return an error from operations that require an upgrade

[Austin Clements]

Previously, there was no protection against a caller invoking an
operation on an old database version that would effectively corrupt
the database by treating it like a newer version.

According to notmuch.h, any caller that opens the database in
read/write mode is supposed to check if the database needs upgrading
and perform an upgrade if it does.  This would protect against this,
but nobody (even the CLI) actually does this.

However, with features, it's easy to protect against incompatible
operations on a fine-grained basis.  This lightweight change allows
callers to safely operate on old database versions, while preventing
specific operations that would corrupt the database with an
informative error message.
---
 lib/database.cc  |  5 +++++
 lib/directory.cc |  5 +++++
 lib/message.cc   |  8 ++++++++
 lib/notmuch.h    | 16 ++++++++++++++++
 4 files changed, 34 insertions(+)

diff --git a/lib/database.cc b/lib/database.cc
index a93281c..f105e27 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -311,6 +311,8 @@ notmuch_status_to_string (notmuch_status_t status)
 	return "Unbalanced number of calls to notmuch_database_begin_atomic/end_atomic";
     case NOTMUCH_STATUS_UNSUPPORTED_OPERATION:
 	return "Unsupported operation";
+    case NOTMUCH_STATUS_UPGRADE_REQUIRED:
+	return "Operation requires a database upgrade";
     default:
     case NOTMUCH_STATUS_LAST_STATUS:
 	return "Unknown error status value";
@@ -2223,6 +2225,9 @@ notmuch_database_find_message_by_filename (notmuch_database_t *notmuch,
     if (message_ret == NULL)
 	return NOTMUCH_STATUS_NULL_POINTER;
 
+    if (! (notmuch->features & NOTMUCH_FEATURE_FILE_TERMS))
+	return NOTMUCH_STATUS_UPGRADE_REQUIRED;
+
     /* return NULL on any failure */
     *message_ret = NULL;
 
diff --git a/lib/directory.cc b/lib/directory.cc
index 6a3ffed..8daaec8 100644
--- a/lib/directory.cc
+++ b/lib/directory.cc
@@ -105,6 +105,11 @@ _notmuch_directory_create (notmuch_database_t *notmuch,
     const char *db_path;
     notmuch_bool_t create = (flags & NOTMUCH_FIND_CREATE);
 
+    if (! (notmuch->features & NOTMUCH_FEATURE_DIRECTORY_DOCS)) {
+	*status_ret = NOTMUCH_STATUS_UPGRADE_REQUIRED;
+	return NULL;
+    }
+
     *status_ret = NOTMUCH_STATUS_SUCCESS;
 
     path = _notmuch_database_relative_path (notmuch, path);
diff --git a/lib/message.cc b/lib/message.cc
index 4fc427f..1618e81 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -653,6 +653,10 @@ _notmuch_message_add_filename (notmuch_message_t *message,
     if (filename == NULL)
 	INTERNAL_ERROR ("Message filename cannot be NULL.");
 
+    if (! (message->notmuch->features & NOTMUCH_FEATURE_FILE_TERMS) ||
+	! (message->notmuch->features & NOTMUCH_FEATURE_BOOL_FOLDER))
+	return NOTMUCH_STATUS_UPGRADE_REQUIRED;
+
     relative = _notmuch_database_relative_path (message->notmuch, filename);
 
     status = _notmuch_database_split_path (local, relative, &directory, NULL);
@@ -697,6 +701,10 @@ _notmuch_message_remove_filename (notmuch_message_t *message,
     notmuch_private_status_t private_status;
     notmuch_status_t status;
 
+    if (! (message->notmuch->features & NOTMUCH_FEATURE_FILE_TERMS) ||
+	! (message->notmuch->features & NOTMUCH_FEATURE_BOOL_FOLDER))
+	return NOTMUCH_STATUS_UPGRADE_REQUIRED;
+
     status = _notmuch_database_filename_to_direntry (
 	local, message->notmuch, filename, NOTMUCH_FIND_LOOKUP, &direntry);
     if (status || !direntry)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 3c5ec98..cbf2ba5 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -160,6 +160,10 @@ typedef enum _notmuch_status {
      */
     NOTMUCH_STATUS_UNSUPPORTED_OPERATION,
     /**
+     * The operation requires a database upgrade.
+     */
+    NOTMUCH_STATUS_UPGRADE_REQUIRED,
+    /**
      * Not an actual status value. Just a way to find out how many
      * valid status values there are.
      */
@@ -438,6 +442,9 @@ notmuch_database_end_atomic (notmuch_database_t *notmuch);
  *
  * NOTMUCH_STATUS_XAPIAN_EXCEPTION: A Xapian exception occurred;
  *	directory not retrieved.
+ *
+ * NOTMUCH_STATUS_UPGRADE_REQUIRED: The caller must upgrade the
+ * 	database to use this function.
  */
 notmuch_status_t
 notmuch_database_get_directory (notmuch_database_t *database,
@@ -490,6 +497,9 @@ notmuch_database_get_directory (notmuch_database_t *database,
  *
  * NOTMUCH_STATUS_READ_ONLY_DATABASE: Database was opened in read-only
  *	mode so no message can be added.
+ *
+ * NOTMUCH_STATUS_UPGRADE_REQUIRED: The caller must upgrade the
+ * 	database to use this function.
  */
 notmuch_status_t
 notmuch_database_add_message (notmuch_database_t *database,
@@ -520,6 +530,9 @@ notmuch_database_add_message (notmuch_database_t *database,
  *
  * NOTMUCH_STATUS_READ_ONLY_DATABASE: Database was opened in read-only
  *	mode so no message can be removed.
+ *
+ * NOTMUCH_STATUS_UPGRADE_REQUIRED: The caller must upgrade the
+ * 	database to use this function.
  */
 notmuch_status_t
 notmuch_database_remove_message (notmuch_database_t *database,
@@ -575,6 +588,9 @@ notmuch_database_find_message (notmuch_database_t *database,
  * NOTMUCH_STATUS_OUT_OF_MEMORY: Out of memory, creating the message object
  *
  * NOTMUCH_STATUS_XAPIAN_EXCEPTION: A Xapian exception occurred
+ *
+ * NOTMUCH_STATUS_UPGRADE_REQUIRED: The caller must upgrade the
+ * 	database to use this function.
  */
 notmuch_status_t
 notmuch_database_find_message_by_filename (notmuch_database_t *notmuch,
-- 
2.0.0

[PATCH 14/14] lib: Update doc of notmuch_database_{needs_upgrade, upgrade}

[Austin Clements]

Clients are no longer required to call these functions after opening a
database in read/write mode (which is good, because almost none of
them do!).
---
 lib/notmuch.h | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/lib/notmuch.h b/lib/notmuch.h
index cbf2ba5..d771eb2 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -352,22 +352,25 @@ unsigned int
 notmuch_database_get_version (notmuch_database_t *database);
 
 /**
- * Does this database need to be upgraded before writing to it?
+ * Is the database behind the latest supported database version?
  *
- * If this function returns TRUE then no functions that modify the
- * database (notmuch_database_add_message, notmuch_message_add_tag,
- * notmuch_directory_set_mtime, etc.) will work unless the function
- * notmuch_database_upgrade is called successfully first.
+ * If this function returns TRUE, then the caller may call
+ * notmuch_database_upgrade to upgrade the database.  If the caller
+ * does not upgrade an out-of-date database, then some functions may
+ * fail with NOTMUCH_STATUS_UPGRADE_REQUIRED.
  */
 notmuch_bool_t
 notmuch_database_needs_upgrade (notmuch_database_t *database);
 
 /**
- * Upgrade the current database.
+ * Upgrade the current database to the latest supported version.
  *
- * 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.
+ * This ensures that all current notmuch functionality will be
+ * available on the database.  After opening a database in read-write
+ * mode, it is recommended that clients check if an upgrade is needed
+ * (notmuch_database_needs_upgrade) and if so, upgrade with this
+ * function before making any modifications.  If
+ * notmuch_database_needs_upgrade returns FALSE, this will be a no-op.
  *
  * The optional progress_notify callback can be used by the caller to
  * provide progress indication to the user. If non-NULL it will be
-- 
2.0.0

Re: [PATCH 07/14] test: Tests for future version and unknown feature handling

[Mark Walters]

On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> ---
>  test/T530-upgrade.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)

Hi

Just a quick comment on this patch so far. After this patch I got lots
of test failures in the second (old) part of T530-upgrade because I
hadn't downloaded the test databases: prior to this patch no tests
failed because those tests were skipped.

Once I downloaded the databases everything was fine again so the problem
is just that this patch is breaking the automatic skipping of the
old tests in T530-upgrade.

Best wishes

Mark

Re: [PATCH 04/14] new: Don't report version after upgrade

[Mark Walters]

On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> The version number has always been pretty meaningless to the user and
> it's about to become even more meaningless with the introduction of
> "features".  Hopefully, the database will remain on version 3 for some
> time to come; however, the introduction of new features over time in
> version 3 will necessitate upgrades within version 3.  It would be
> confusing if we always tell the user they've been "upgraded to version
> 3".  If the user wants to know what's new, they should read the news.

Two thoughts on this: 

first, we could print the names of the new features here to make it
easier for the user to find them in NEWS. 

Secondly, would it be worth having something like notmuch
--database-version or similar which prints the features? If I understand
the series then notmuch clients don't necessarily need to upgrade the
database unless they want the new features. This means that knowing what
version they are running might not tell us which features they have
enabled (which could make debugging difficult)

Best wishes

Mark

> ---
>  notmuch-new.c        | 3 +--
>  test/T530-upgrade.sh | 2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/notmuch-new.c b/notmuch-new.c
> index d269c7c..b7590a8 100644
> --- a/notmuch-new.c
> +++ b/notmuch-new.c
> @@ -1023,8 +1023,7 @@ notmuch_new_command (notmuch_config_t *config, int argc, char *argv[])
>  				      add_files_state.verbosity >= VERBOSITY_NORMAL ? upgrade_print_progress : NULL,
>  				      &add_files_state);
>  	    if (add_files_state.verbosity >= VERBOSITY_NORMAL)
> -		printf ("Your notmuch database has now been upgraded to database format version %u.\n",
> -		    notmuch_database_get_version (notmuch));
> +		printf ("Your notmuch database has now been upgraded.\n");
>  	}
>  
>  	add_files_state.total_files = 0;
> diff --git a/test/T530-upgrade.sh b/test/T530-upgrade.sh
> index 7d5d5aa..c4c4ac8 100755
> --- a/test/T530-upgrade.sh
> +++ b/test/T530-upgrade.sh
> @@ -33,7 +33,7 @@ test_expect_equal "$output" "\
>  Welcome to a new version of notmuch! Your database will now be upgraded.
>  This process is safe to interrupt.
>  Backing up tags to FILENAME
> -Your notmuch database has now been upgraded to database format version 2.
> +Your notmuch database has now been upgraded.
>  No new mail."
>  
>  test_begin_subtest "tag backup matches pre-upgrade dump"
> -- 
> 2.0.0
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 08/14] lib: Simplify upgrade code using a transaction

[Mark Walters]

Hi

On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> Previously, the upgrade was organized as two passes -- an upgrade
> pass, and a separate cleanup pass -- so the database was always in a
> valid state.  This change substantially simplifies this code by
> performing the upgrade in a transaction and combining both passes in
> to one.  This 1) eliminates a lot of duplicate code between the
> passes, 2) speeds up the upgrade process, 3) makes progress reporting
> more accurate, 4) eliminates the potential for stale data if the
> upgrade is interrupted during the cleanup pass, and 5) makes it easier
> to reason about the safety of the upgrade code.

I like this but I wonder if it has a side effect: I think with the
current code the user can interrupt the upgrade (ctrl-c) and continue
roughly where it left off. This looks like it means the whole upgrade
needs to be done in one go. Will this be a problem on large mail stores
(eg rlb with over 1M messages)?

I am not sure what could be done during the interrupted upgrade before
so maybe this is not a problem.

Best wishes

Mark


> ---
>  lib/database.cc | 67 ++++++---------------------------------------------------
>  1 file changed, 7 insertions(+), 60 deletions(-)
>
> diff --git a/lib/database.cc b/lib/database.cc
> index 03eef3e..0be7180 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -1238,6 +1238,9 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>  	timer_is_active = TRUE;
>      }
>  
> +    /* Perform the upgrade in a transaction. */
> +    db->begin_transaction (true);
> +
>      /* Before version 1, each message document had its filename in the
>       * data field. Copy that into the new format by calling
>       * notmuch_message_add_filename.
> @@ -1265,6 +1268,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>  	    filename = _notmuch_message_talloc_copy_data (message);
>  	    if (filename && *filename != '\0') {
>  		_notmuch_message_add_filename (message, filename);
> +		_notmuch_message_clear_data (message);
>  		_notmuch_message_sync (message);
>  	    }
>  	    talloc_free (filename);
> @@ -1312,6 +1316,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>  						       NOTMUCH_FIND_CREATE, &status);
>  		notmuch_directory_set_mtime (directory, mtime);
>  		notmuch_directory_destroy (directory);
> +
> +		db->delete_document (*p);
>  	    }
>  	}
>      }
> @@ -1353,67 +1359,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>      notmuch->features |= NOTMUCH_FEATURES_CURRENT;
>      db->set_metadata ("features", _print_features (local, notmuch->features));
>      db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
> -    db->flush ();
> -
> -    /* 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);
> -	     notmuch_messages_valid (messages);
> -	     notmuch_messages_move_to_next (messages))
> -	{
> -	    if (do_progress_notify) {
> -		progress_notify (closure, (double) count / total);
> -		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++)
> -	    {
> -		if (do_progress_notify) {
> -		    progress_notify (closure, (double) count / total);
> -		    do_progress_notify = 0;
> -		}
> -
> -		db->delete_document (*p);
> -	    }
> -	}
> -    }
> +    db->commit_transaction ();
>  
>      if (timer_is_active) {
>  	/* Now stop the timer. */
> -- 
> 2.0.0
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 05/14] lib: Database version 3: Introduce fine-grained "features"

[Mark Walters]

On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> Previously, our database schema was versioned by a single number.
> Each database schema change had to occur "atomically" in Notmuch's
> development history: before some commit, Notmuch used version N, after
> that commit, it used version N+1.  Hence, each new schema version
> could introduce only one change, the task of developing a schema
> change fell on a single person, and it all had to happen and be
> perfect in a single commit series.  This made introducing a new schema
> version hard.  We've seen only two schema changes in the history of
> Notmuch.

I like this series as a whole and I am happy with all the patches that I
haven't sent comments on. (Note, however, that I am not very familiar
with the database code.)

There is one thing which confuses me in this patch:

>
> This commit introduces database schema version 3; hopefully the last
> schema version we'll need for a while.  With this version, we switch
> from a single version number to "features": a set of named,
> independent aspects of the database schema.
>
> Features should make backwards compatibility easier.  For many things,
> it should be easy to support databases both with and without a
> feature, which will allow us to make upgrades optional and will enable
> "unstable" features that can be developed and tested over time.
>
> Features also make forwards compatibility easier.  The features
> recorded in a database include "compatibility flags," which can
> indicate to an older version of Notmuch when it must support a given
> feature to open the database for read or for write.  This lets us
> replace the old vague "I don't recognize this version, so something
> might go wrong, but I promise to try my best" warnings upon opening a
> database with an unknown version with precise errors.  If a database
> is safe to open for read/write despite unknown features, an older
> version will know that and issue no message at all.  If the database
> is not safe to open for read/write because of unknown features, an
> older version will know that, too, and can tell the user exactly which
> required features it lacks support for.
> ---
>  lib/database-private.h |  56 +++++++++++++++
>  lib/database.cc        | 189 +++++++++++++++++++++++++++++++++++++++++--------
>  2 files changed, 214 insertions(+), 31 deletions(-)
>
> diff --git a/lib/database-private.h b/lib/database-private.h
> index d3e65fd..323b9fe 100644
> --- a/lib/database-private.h
> +++ b/lib/database-private.h
> @@ -46,6 +46,11 @@ struct _notmuch_database {
>      int atomic_nesting;
>      Xapian::Database *xapian_db;
>  
> +    /* Bit mask of features used by this database.  Features are
> +     * named, independent aspects of the database schema.  This is a
> +     * bitwise-OR of NOTMUCH_FEATURE_* values (below). */
> +    unsigned int features;
> +
>      unsigned int last_doc_id;
>      uint64_t last_thread_id;
>  
> @@ -55,6 +60,57 @@ struct _notmuch_database {
>      Xapian::ValueRangeProcessor *date_range_processor;
>  };
>  
> +/* Bit masks for _notmuch_database::features. */
> +enum {
> +    /* If set, file names are stored in "file-direntry" terms.  If
> +     * unset, file names are stored in document data.
> +     *
> +     * Introduced: version 1.  Implementation support: both for read;
> +     * required for write. */
> +    NOTMUCH_FEATURE_FILE_TERMS = 1 << 0,
> +
> +    /* If set, directory timestamps are stored in documents with
> +     * XDIRECTORY terms and relative paths.  If unset, directory
> +     * timestamps are stored in documents with XTIMESTAMP terms and
> +     * absolute paths.
> +     *
> +     * Introduced: version 1.  Implementation support: required. */
> +    NOTMUCH_FEATURE_DIRECTORY_DOCS = 1 << 1,
> +
> +    /* If set, the from, subject, and message-id headers are stored in
> +     * message document values.  If unset, message documents *may*
> +     * have these values, but if the value is empty, it must be
> +     * retrieved from the message file.
> +     *
> +     * Introduced: optional in version 1, required as of version 3.
> +     * Implementation support: both.
> +     */
> +    NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES = 1 << 2,
> +
> +    /* If set, folder terms are boolean and path terms exist.  If
> +     * unset, folder terms are probabilistic and stemmed and path
> +     * terms do not exist.
> +     *
> +     * Introduced: version 2.  Implementation support: required. */
> +    NOTMUCH_FEATURE_BOOL_FOLDER = 1 << 3,
> +};
> +
> +/* Prior to database version 3, features were implied by the database
> + * version number, so hard-code them for earlier versions. */
> +#define NOTMUCH_FEATURES_V0 (0)
> +#define NOTMUCH_FEATURES_V1 (NOTMUCH_FEATURES_V0 | NOTMUCH_FEATURE_FILE_TERMS | \
> +			     NOTMUCH_FEATURE_DIRECTORY_DOCS)
> +#define NOTMUCH_FEATURES_V2 (NOTMUCH_FEATURES_V1 | NOTMUCH_FEATURE_BOOL_FOLDER)
> +
> +/* Current database features.  If any of these are missing from a
> + * database, request an upgrade.
> + * NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES is not included because
> + * upgrade doesn't currently introduce the feature (though brand new
> + * databases will have it). */
> +#define NOTMUCH_FEATURES_CURRENT \
> +    (NOTMUCH_FEATURE_FILE_TERMS | NOTMUCH_FEATURE_DIRECTORY_DOCS | \
> +     NOTMUCH_FEATURE_BOOL_FOLDER)
> +
>  /* Return the list of terms from the given iterator matching a prefix.
>   * The prefix will be stripped from the strings in the returned list.
>   * The list will be allocated using ctx as the talloc context.
> diff --git a/lib/database.cc b/lib/database.cc
> index 45c4260..03eef3e 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -20,6 +20,7 @@
>  
>  #include "database-private.h"
>  #include "parse-time-vrp.h"
> +#include "string-util.h"
>  
>  #include <iostream>
>  
> @@ -42,7 +43,7 @@ typedef struct {
>      const char *prefix;
>  } prefix_t;
>  
> -#define NOTMUCH_DATABASE_VERSION 2
> +#define NOTMUCH_DATABASE_VERSION 3
>  
>  #define STRINGIFY(s) _SUB_STRINGIFY(s)
>  #define _SUB_STRINGIFY(s) #s
> @@ -151,6 +152,17 @@ typedef struct {
>   *			changes are made to the database (such as by
>   *			indexing new fields).
>   *
> + *	features	The set of features supported by this
> + *			database. This consists of a set of
> + *			'\n'-separated lines, where each is a feature
> + *			name, a '\t', and compatibility flags.  If the
> + *			compatibility flags contain 'w', then the
> + *			opener must support this feature to safely
> + *			write this database.  If the compatibility
> + *			flags contain 'r', then the opener must
> + *			support this feature to read this database.
> + *			Introduced in database version 3.
> + *
>   *	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
> @@ -226,6 +238,7 @@ static prefix_t PROBABILISTIC_PREFIX[]= {
>      { "subject",		"XSUBJECT"},
>  };
>  
> +
>  const char *
>  _find_prefix (const char *name)
>  {
> @@ -251,6 +264,25 @@ _find_prefix (const char *name)
>      return "";
>  }
>  
> +static const struct
> +{
> +    /* NOTMUCH_FEATURE_* value. */
> +    unsigned int value;
> +    /* Feature name as it appears in the database.  This name should
> +     * be appropriate for displaying to the user if an older version
> +     * of notmuch doesn't support this feature. */
> +    const char *name;
> +    /* Compatibility flags when this feature is declared. */
> +    const char *flags;
> +} feature_names[] = {
> +    {NOTMUCH_FEATURE_FILE_TERMS,             "file terms", "rw"},
> +    {NOTMUCH_FEATURE_DIRECTORY_DOCS,         "directory documents", "rw"},
> +    /* Header values are not required for reading a database because a
> +     * reader can just refer to the message file. */
> +    {NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES, "from/subject/ID values", "w"},
> +    {NOTMUCH_FEATURE_BOOL_FOLDER,            "boolean folder terms", "rw"},
> +};
> +
>  const char *
>  notmuch_status_to_string (notmuch_status_t status)
>  {
> @@ -591,6 +623,11 @@ notmuch_database_create (const char *path, notmuch_database_t **database)
>  				    &notmuch);
>      if (status)
>  	goto DONE;
> +
> +    /* Upgrade doesn't add this feature to existing databases, but new
> +     * databases have it. */
> +    notmuch->features |= NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES;
> +

Does this mean that if the user wants this feature he has to dump,
delete the existing database, and restore? Is that just because no-one
has implemented upgrade for this feature or is it "hard" in some sense?

A possibly related question: is there likely to be a case where the user
does not want to add/upgrade some feature? Would it be worth having an
explicit upgrade command which let the user choose which features to
upgrade? This is orthogonal to this series: I am just trying to get a
feel for how it will, or could, be used.

Best wishes

Mark

>      status = notmuch_database_upgrade (notmuch, NULL, NULL);
>      if (status) {
>  	notmuch_database_close(notmuch);
> @@ -619,6 +656,80 @@ _notmuch_database_ensure_writable (notmuch_database_t *notmuch)
>      return NOTMUCH_STATUS_SUCCESS;
>  }
>  
> +/* Parse a database features string from the given database version.
> + *
> + * For version < 3, this ignores the features string and returns a
> + * hard-coded set of features.
> + *
> + * If there are unrecognized features that are required to open the
> + * database in mode (which should be 'r' or 'w'), return a
> + * comma-separated list of unrecognized but required features in
> + * *incompat_out, which will be allocated from ctx.
> + */
> +static unsigned int
> +_parse_features (const void *ctx, const char *features, unsigned int version,
> +		 char mode, char **incompat_out)
> +{
> +    unsigned int res = 0, namelen, i;
> +    size_t llen = 0;
> +    const char *flags;
> +
> +    /* Prior to database version 3, features were implied by the
> +     * version number. */
> +    if (version == 0)
> +	return NOTMUCH_FEATURES_V0;
> +    else if (version == 1)
> +	return NOTMUCH_FEATURES_V1;
> +    else if (version == 2)
> +	return NOTMUCH_FEATURES_V2;
> +
> +    /* Parse the features string */
> +    while ((features = strtok_len_c (features + llen, "\n", &llen)) != NULL) {
> +	flags = strchr (features, '\t');
> +	if (! flags || flags > features + llen)
> +	    continue;
> +	namelen = flags - features;
> +
> +	for (i = 0; i < ARRAY_SIZE (feature_names); ++i) {
> +	    if (strlen (feature_names[i].name) == namelen &&
> +		strncmp (feature_names[i].name, features, namelen) == 0) {
> +		res |= feature_names[i].value;
> +		break;
> +	    }
> +	}
> +
> +	if (i == ARRAY_SIZE (feature_names)) {
> +	    /* Unrecognized feature */
> +	    const char *have = strchr (flags, mode);
> +	    if (have && have < features + llen) {
> +		/* This feature is required to access this database in
> +		 * 'mode', but we don't understand it. */
> +		if (! *incompat_out)
> +		    *incompat_out = talloc_strdup (ctx, "");
> +		*incompat_out = talloc_asprintf_append_buffer (
> +		    *incompat_out, "%s%.*s", **incompat_out ? ", " : "",
> +		    namelen, features);
> +	    }
> +	}
> +    }
> +
> +    return res;
> +}
> +
> +static char *
> +_print_features (const void *ctx, unsigned int features)
> +{
> +    unsigned int i;
> +    char *res = talloc_strdup (ctx, "");
> +
> +    for (i = 0; i < ARRAY_SIZE (feature_names); ++i)
> +	if (features & feature_names[i].value)
> +	    res = talloc_asprintf_append_buffer (
> +		res, "%s\t%s\n", feature_names[i].name, feature_names[i].flags);
> +
> +    return res;
> +}
> +
>  notmuch_status_t
>  notmuch_database_open (const char *path,
>  		       notmuch_database_mode_t mode,
> @@ -627,7 +738,7 @@ notmuch_database_open (const char *path,
>      notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
>      void *local = talloc_new (NULL);
>      notmuch_database_t *notmuch = NULL;
> -    char *notmuch_path, *xapian_path;
> +    char *notmuch_path, *xapian_path, *incompat_features;
>      struct stat st;
>      int err;
>      unsigned int i, version;
> @@ -686,39 +797,51 @@ notmuch_database_open (const char *path,
>  	if (mode == NOTMUCH_DATABASE_MODE_READ_WRITE) {
>  	    notmuch->xapian_db = new Xapian::WritableDatabase (xapian_path,
>  							       Xapian::DB_CREATE_OR_OPEN);
> -	    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_destroy (notmuch);
> -		notmuch = NULL;
> -		status = NOTMUCH_STATUS_FILE_ERROR;
> -		goto DONE;
> -	    }
> -
> -	    if (version < NOTMUCH_DATABASE_VERSION)
> -		notmuch->needs_upgrade = TRUE;
>  	} else {
>  	    notmuch->xapian_db = new Xapian::Database (xapian_path);
> -	    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);
> -	    }
>  	}
>  
> +	/* Check version.  As of database version 3, we represent
> +	 * changes in terms of features, so assume a version bump
> +	 * means a dramatically incompatible change. */
> +	version = notmuch_database_get_version (notmuch);
> +	if (version > NOTMUCH_DATABASE_VERSION) {
> +	    fprintf (stderr,
> +		     "Error: Notmuch database at %s\n"
> +		     "       has a newer database format version (%u) than supported by this\n"
> +		     "       version of notmuch (%u).\n",
> +		     notmuch_path, version, NOTMUCH_DATABASE_VERSION);
> +	    notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
> +	    notmuch_database_destroy (notmuch);
> +	    notmuch = NULL;
> +	    status = NOTMUCH_STATUS_FILE_ERROR;
> +	    goto DONE;
> +	}
> +
> +	/* Check features. */
> +	incompat_features = NULL;
> +	notmuch->features = _parse_features (
> +	    local, notmuch->xapian_db->get_metadata ("features").c_str (),
> +	    version, mode == NOTMUCH_DATABASE_MODE_READ_WRITE ? 'w' : 'r',
> +	    &incompat_features);
> +	if (incompat_features) {
> +	    fprintf (stderr,
> +		     "Error: Notmuch database at %s\n"
> +		     "       requires features (%s)\n"
> +		     "       not supported by this version of notmuch.\n",
> +		     notmuch_path, incompat_features);
> +	    notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
> +	    notmuch_database_destroy (notmuch);
> +	    notmuch = NULL;
> +	    status = NOTMUCH_STATUS_FILE_ERROR;
> +	    goto DONE;
> +	}
> +
> +	/* Do we want an upgrade? */
> +	if (mode == NOTMUCH_DATABASE_MODE_READ_WRITE &&
> +	    NOTMUCH_FEATURES_CURRENT & ~notmuch->features)
> +	    notmuch->needs_upgrade = TRUE;
> +
>  	notmuch->last_doc_id = notmuch->xapian_db->get_lastdocid ();
>  	last_thread_id = notmuch->xapian_db->get_metadata ("last_thread_id");
>  	if (last_thread_id.empty ()) {
> @@ -1077,6 +1200,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>  						   double progress),
>  			  void *closure)
>  {
> +    void *local = talloc_new (NULL);
>      Xapian::WritableDatabase *db;
>      struct sigaction action;
>      struct itimerval timerval;
> @@ -1226,6 +1350,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>  	notmuch_query_destroy (query);
>      }
>  
> +    notmuch->features |= NOTMUCH_FEATURES_CURRENT;
> +    db->set_metadata ("features", _print_features (local, notmuch->features));
>      db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
>      db->flush ();
>  
> @@ -1302,6 +1428,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>  	sigaction (SIGALRM, &action, NULL);
>      }
>  
> +    talloc_free (local);
>      return NOTMUCH_STATUS_SUCCESS;
>  }
>  
> -- 
> 2.0.0
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 07/14] test: Tests for future version and unknown feature handling

[Austin Clements]

Quoth Mark Walters on Jul 27 at  9:51 am:
> 
> On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> > ---
> >  test/T530-upgrade.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 46 insertions(+)
> 
> Hi
> 
> Just a quick comment on this patch so far. After this patch I got lots
> of test failures in the second (old) part of T530-upgrade because I
> hadn't downloaded the test databases: prior to this patch no tests
> failed because those tests were skipped.
> 
> Once I downloaded the databases everything was fine again so the problem
> is just that this patch is breaking the automatic skipping of the
> old tests in T530-upgrade.

Oh.  Apparently the prereq stuff only works before the first call to
test_begin_subtest.  Maybe I should just move the subtests I added to
a separate top-level test?

Re: [PATCH 04/14] new: Don't report version after upgrade

[Austin Clements]

Quoth Mark Walters on Jul 27 at 10:33 am:
> On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> > The version number has always been pretty meaningless to the user and
> > it's about to become even more meaningless with the introduction of
> > "features".  Hopefully, the database will remain on version 3 for some
> > time to come; however, the introduction of new features over time in
> > version 3 will necessitate upgrades within version 3.  It would be
> > confusing if we always tell the user they've been "upgraded to version
> > 3".  If the user wants to know what's new, they should read the news.
> 
> Two thoughts on this: 
> 
> first, we could print the names of the new features here to make it
> easier for the user to find them in NEWS. 

Interesting.  Transparency is good, though I worry that this would
expose the user to internal implementation details (certainly some
features will translate to user-visible features, but others will be
entirely internal to the library).

> Secondly, would it be worth having something like notmuch
> --database-version or similar which prints the features? If I understand
> the series then notmuch clients don't necessarily need to upgrade the
> database unless they want the new features. This means that knowing what
> version they are running might not tell us which features they have
> enabled (which could make debugging difficult)

Good idea, though I'd be inclined to do it in a follow-up series just
so this series doesn't get even longer.  It won't be a problem for
now: this series doesn't touch our current policy of unconditionally
upgrading on notmuch new (a policy I think we should keep, though
that's a separate discussion) so the notmuch version should still tell
us the database version/features.

> Best wishes
> 
> Mark
> 
> > ---
> >  notmuch-new.c        | 3 +--
> >  test/T530-upgrade.sh | 2 +-
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/notmuch-new.c b/notmuch-new.c
> > index d269c7c..b7590a8 100644
> > --- a/notmuch-new.c
> > +++ b/notmuch-new.c
> > @@ -1023,8 +1023,7 @@ notmuch_new_command (notmuch_config_t *config, int argc, char *argv[])
> >  				      add_files_state.verbosity >= VERBOSITY_NORMAL ? upgrade_print_progress : NULL,
> >  				      &add_files_state);
> >  	    if (add_files_state.verbosity >= VERBOSITY_NORMAL)
> > -		printf ("Your notmuch database has now been upgraded to database format version %u.\n",
> > -		    notmuch_database_get_version (notmuch));
> > +		printf ("Your notmuch database has now been upgraded.\n");
> >  	}
> >  
> >  	add_files_state.total_files = 0;
> > diff --git a/test/T530-upgrade.sh b/test/T530-upgrade.sh
> > index 7d5d5aa..c4c4ac8 100755
> > --- a/test/T530-upgrade.sh
> > +++ b/test/T530-upgrade.sh
> > @@ -33,7 +33,7 @@ test_expect_equal "$output" "\
> >  Welcome to a new version of notmuch! Your database will now be upgraded.
> >  This process is safe to interrupt.
> >  Backing up tags to FILENAME
> > -Your notmuch database has now been upgraded to database format version 2.
> > +Your notmuch database has now been upgraded.
> >  No new mail."
> >  
> >  test_begin_subtest "tag backup matches pre-upgrade dump"

Re: [PATCH 08/14] lib: Simplify upgrade code using a transaction

[Austin Clements]

Quoth Mark Walters on Jul 27 at 10:35 am:
> 
> Hi
> 
> On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> > Previously, the upgrade was organized as two passes -- an upgrade
> > pass, and a separate cleanup pass -- so the database was always in a
> > valid state.  This change substantially simplifies this code by
> > performing the upgrade in a transaction and combining both passes in
> > to one.  This 1) eliminates a lot of duplicate code between the
> > passes, 2) speeds up the upgrade process, 3) makes progress reporting
> > more accurate, 4) eliminates the potential for stale data if the
> > upgrade is interrupted during the cleanup pass, and 5) makes it easier
> > to reason about the safety of the upgrade code.
> 
> I like this but I wonder if it has a side effect: I think with the
> current code the user can interrupt the upgrade (ctrl-c) and continue
> roughly where it left off. This looks like it means the whole upgrade
> needs to be done in one go. Will this be a problem on large mail stores
> (eg rlb with over 1M messages)?
> 
> I am not sure what could be done during the interrupted upgrade before
> so maybe this is not a problem.

I haven't tested this hypothesis, but I don't think a partially
completed upgrade would actually help upon restarting the upgrade.
Since the old upgrade process couldn't safely remove terms/data until
the end of the upgrade, if it were interrupted, the next upgrade would
start right back at the beginning and do everything over again.

Also, since the old upgrade code had to update the version number
before removing old terms/data, if it was interrupted during the
cleanup process the database would be left with cruft that would
*never* be removed.

With features we actually have a better chance of making partially
completed upgrades useful: we could commit after each individual
feature gets upgraded.  Of course, that only helps when upgrade has
multiple new features to upgrade to, so it may or may not be useful in
practice depending on how quickly we add new features.

> Best wishes
> 
> Mark
> 
> 
> > ---
> >  lib/database.cc | 67 ++++++---------------------------------------------------
> >  1 file changed, 7 insertions(+), 60 deletions(-)
> >
> > diff --git a/lib/database.cc b/lib/database.cc
> > index 03eef3e..0be7180 100644
> > --- a/lib/database.cc
> > +++ b/lib/database.cc
> > @@ -1238,6 +1238,9 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
> >  	timer_is_active = TRUE;
> >      }
> >  
> > +    /* Perform the upgrade in a transaction. */
> > +    db->begin_transaction (true);
> > +
> >      /* Before version 1, each message document had its filename in the
> >       * data field. Copy that into the new format by calling
> >       * notmuch_message_add_filename.
> > @@ -1265,6 +1268,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
> >  	    filename = _notmuch_message_talloc_copy_data (message);
> >  	    if (filename && *filename != '\0') {
> >  		_notmuch_message_add_filename (message, filename);
> > +		_notmuch_message_clear_data (message);
> >  		_notmuch_message_sync (message);
> >  	    }
> >  	    talloc_free (filename);
> > @@ -1312,6 +1316,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
> >  						       NOTMUCH_FIND_CREATE, &status);
> >  		notmuch_directory_set_mtime (directory, mtime);
> >  		notmuch_directory_destroy (directory);
> > +
> > +		db->delete_document (*p);
> >  	    }
> >  	}
> >      }
> > @@ -1353,67 +1359,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
> >      notmuch->features |= NOTMUCH_FEATURES_CURRENT;
> >      db->set_metadata ("features", _print_features (local, notmuch->features));
> >      db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
> > -    db->flush ();
> > -
> > -    /* 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);
> > -	     notmuch_messages_valid (messages);
> > -	     notmuch_messages_move_to_next (messages))
> > -	{
> > -	    if (do_progress_notify) {
> > -		progress_notify (closure, (double) count / total);
> > -		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++)
> > -	    {
> > -		if (do_progress_notify) {
> > -		    progress_notify (closure, (double) count / total);
> > -		    do_progress_notify = 0;
> > -		}
> > -
> > -		db->delete_document (*p);
> > -	    }
> > -	}
> > -    }
> > +    db->commit_transaction ();
> >  
> >      if (timer_is_active) {
> >  	/* Now stop the timer. */
> >

Re: [PATCH 05/14] lib: Database version 3: Introduce fine-grained "features"

[Austin Clements]

Quoth Mark Walters on Jul 27 at 10:53 am:
> 
> On Sun, 27 Jul 2014, Austin Clements <amdragon@MIT.EDU> wrote:
> > Previously, our database schema was versioned by a single number.
> > Each database schema change had to occur "atomically" in Notmuch's
> > development history: before some commit, Notmuch used version N, after
> > that commit, it used version N+1.  Hence, each new schema version
> > could introduce only one change, the task of developing a schema
> > change fell on a single person, and it all had to happen and be
> > perfect in a single commit series.  This made introducing a new schema
> > version hard.  We've seen only two schema changes in the history of
> > Notmuch.
> 
> I like this series as a whole and I am happy with all the patches that I
> haven't sent comments on. (Note, however, that I am not very familiar
> with the database code.)
> 
> There is one thing which confuses me in this patch:
> 
> >
> > This commit introduces database schema version 3; hopefully the last
> > schema version we'll need for a while.  With this version, we switch
> > from a single version number to "features": a set of named,
> > independent aspects of the database schema.
> >
> > Features should make backwards compatibility easier.  For many things,
> > it should be easy to support databases both with and without a
> > feature, which will allow us to make upgrades optional and will enable
> > "unstable" features that can be developed and tested over time.
> >
> > Features also make forwards compatibility easier.  The features
> > recorded in a database include "compatibility flags," which can
> > indicate to an older version of Notmuch when it must support a given
> > feature to open the database for read or for write.  This lets us
> > replace the old vague "I don't recognize this version, so something
> > might go wrong, but I promise to try my best" warnings upon opening a
> > database with an unknown version with precise errors.  If a database
> > is safe to open for read/write despite unknown features, an older
> > version will know that and issue no message at all.  If the database
> > is not safe to open for read/write because of unknown features, an
> > older version will know that, too, and can tell the user exactly which
> > required features it lacks support for.
> > ---
> >  lib/database-private.h |  56 +++++++++++++++
> >  lib/database.cc        | 189 +++++++++++++++++++++++++++++++++++++++++--------
> >  2 files changed, 214 insertions(+), 31 deletions(-)
> >
> > diff --git a/lib/database-private.h b/lib/database-private.h
> > index d3e65fd..323b9fe 100644
> > --- a/lib/database-private.h
> > +++ b/lib/database-private.h
> > @@ -46,6 +46,11 @@ struct _notmuch_database {
> >      int atomic_nesting;
> >      Xapian::Database *xapian_db;
> >  
> > +    /* Bit mask of features used by this database.  Features are
> > +     * named, independent aspects of the database schema.  This is a
> > +     * bitwise-OR of NOTMUCH_FEATURE_* values (below). */
> > +    unsigned int features;
> > +
> >      unsigned int last_doc_id;
> >      uint64_t last_thread_id;
> >  
> > @@ -55,6 +60,57 @@ struct _notmuch_database {
> >      Xapian::ValueRangeProcessor *date_range_processor;
> >  };
> >  
> > +/* Bit masks for _notmuch_database::features. */
> > +enum {
> > +    /* If set, file names are stored in "file-direntry" terms.  If
> > +     * unset, file names are stored in document data.
> > +     *
> > +     * Introduced: version 1.  Implementation support: both for read;
> > +     * required for write. */
> > +    NOTMUCH_FEATURE_FILE_TERMS = 1 << 0,
> > +
> > +    /* If set, directory timestamps are stored in documents with
> > +     * XDIRECTORY terms and relative paths.  If unset, directory
> > +     * timestamps are stored in documents with XTIMESTAMP terms and
> > +     * absolute paths.
> > +     *
> > +     * Introduced: version 1.  Implementation support: required. */
> > +    NOTMUCH_FEATURE_DIRECTORY_DOCS = 1 << 1,
> > +
> > +    /* If set, the from, subject, and message-id headers are stored in
> > +     * message document values.  If unset, message documents *may*
> > +     * have these values, but if the value is empty, it must be
> > +     * retrieved from the message file.
> > +     *
> > +     * Introduced: optional in version 1, required as of version 3.
> > +     * Implementation support: both.
> > +     */
> > +    NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES = 1 << 2,
> > +
> > +    /* If set, folder terms are boolean and path terms exist.  If
> > +     * unset, folder terms are probabilistic and stemmed and path
> > +     * terms do not exist.
> > +     *
> > +     * Introduced: version 2.  Implementation support: required. */
> > +    NOTMUCH_FEATURE_BOOL_FOLDER = 1 << 3,
> > +};
> > +
> > +/* Prior to database version 3, features were implied by the database
> > + * version number, so hard-code them for earlier versions. */
> > +#define NOTMUCH_FEATURES_V0 (0)
> > +#define NOTMUCH_FEATURES_V1 (NOTMUCH_FEATURES_V0 | NOTMUCH_FEATURE_FILE_TERMS | \
> > +			     NOTMUCH_FEATURE_DIRECTORY_DOCS)
> > +#define NOTMUCH_FEATURES_V2 (NOTMUCH_FEATURES_V1 | NOTMUCH_FEATURE_BOOL_FOLDER)
> > +
> > +/* Current database features.  If any of these are missing from a
> > + * database, request an upgrade.
> > + * NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES is not included because
> > + * upgrade doesn't currently introduce the feature (though brand new
> > + * databases will have it). */
> > +#define NOTMUCH_FEATURES_CURRENT \
> > +    (NOTMUCH_FEATURE_FILE_TERMS | NOTMUCH_FEATURE_DIRECTORY_DOCS | \
> > +     NOTMUCH_FEATURE_BOOL_FOLDER)
> > +
> >  /* Return the list of terms from the given iterator matching a prefix.
> >   * The prefix will be stripped from the strings in the returned list.
> >   * The list will be allocated using ctx as the talloc context.
> > diff --git a/lib/database.cc b/lib/database.cc
> > index 45c4260..03eef3e 100644
> > --- a/lib/database.cc
> > +++ b/lib/database.cc
> > @@ -20,6 +20,7 @@
> >  
> >  #include "database-private.h"
> >  #include "parse-time-vrp.h"
> > +#include "string-util.h"
> >  
> >  #include <iostream>
> >  
> > @@ -42,7 +43,7 @@ typedef struct {
> >      const char *prefix;
> >  } prefix_t;
> >  
> > -#define NOTMUCH_DATABASE_VERSION 2
> > +#define NOTMUCH_DATABASE_VERSION 3
> >  
> >  #define STRINGIFY(s) _SUB_STRINGIFY(s)
> >  #define _SUB_STRINGIFY(s) #s
> > @@ -151,6 +152,17 @@ typedef struct {
> >   *			changes are made to the database (such as by
> >   *			indexing new fields).
> >   *
> > + *	features	The set of features supported by this
> > + *			database. This consists of a set of
> > + *			'\n'-separated lines, where each is a feature
> > + *			name, a '\t', and compatibility flags.  If the
> > + *			compatibility flags contain 'w', then the
> > + *			opener must support this feature to safely
> > + *			write this database.  If the compatibility
> > + *			flags contain 'r', then the opener must
> > + *			support this feature to read this database.
> > + *			Introduced in database version 3.
> > + *
> >   *	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
> > @@ -226,6 +238,7 @@ static prefix_t PROBABILISTIC_PREFIX[]= {
> >      { "subject",		"XSUBJECT"},
> >  };
> >  
> > +
> >  const char *
> >  _find_prefix (const char *name)
> >  {
> > @@ -251,6 +264,25 @@ _find_prefix (const char *name)
> >      return "";
> >  }
> >  
> > +static const struct
> > +{
> > +    /* NOTMUCH_FEATURE_* value. */
> > +    unsigned int value;
> > +    /* Feature name as it appears in the database.  This name should
> > +     * be appropriate for displaying to the user if an older version
> > +     * of notmuch doesn't support this feature. */
> > +    const char *name;
> > +    /* Compatibility flags when this feature is declared. */
> > +    const char *flags;
> > +} feature_names[] = {
> > +    {NOTMUCH_FEATURE_FILE_TERMS,             "file terms", "rw"},
> > +    {NOTMUCH_FEATURE_DIRECTORY_DOCS,         "directory documents", "rw"},
> > +    /* Header values are not required for reading a database because a
> > +     * reader can just refer to the message file. */
> > +    {NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES, "from/subject/ID values", "w"},
> > +    {NOTMUCH_FEATURE_BOOL_FOLDER,            "boolean folder terms", "rw"},
> > +};
> > +
> >  const char *
> >  notmuch_status_to_string (notmuch_status_t status)
> >  {
> > @@ -591,6 +623,11 @@ notmuch_database_create (const char *path, notmuch_database_t **database)
> >  				    &notmuch);
> >      if (status)
> >  	goto DONE;
> > +
> > +    /* Upgrade doesn't add this feature to existing databases, but new
> > +     * databases have it. */
> > +    notmuch->features |= NOTMUCH_FEATURE_FROM_SUBJECT_ID_VALUES;
> > +
> 
> Does this mean that if the user wants this feature he has to dump,
> delete the existing database, and restore? Is that just because no-one
> has implemented upgrade for this feature or is it "hard" in some sense?

Yep.  But note that while this feature bit *guarantees* that these
values will be available, if this feature bit isn't set, the code will
still check for these values and use them if they're present.

Implementing an upgrade for this feature is "hard" in the sense that
it requires parsing messages to fill in missing values.  Currently,
all upgrades operate on the database exclusively, without going back
to the original messages.  I doubt we'll be able to keep that up
forever, but that's what's going on now.  (It'll be tricky to deal
with when we do need it, since the database may not be up-to-date with
the mail store, so we may not be able to open all messages!)

> A possibly related question: is there likely to be a case where the user
> does not want to add/upgrade some feature? Would it be worth having an
> explicit upgrade command which let the user choose which features to
> upgrade? This is orthogonal to this series: I am just trying to get a
> feel for how it will, or could, be used.

Good question.  My gut feeling is that we should try to avoid this in
the general case because this sort of "feature fragmentation" would
complicate the code, as well as testing and debugging.

There are a few potential uses I can think of, though.  One relates to
what I was saying above: if some upgrade requires reindexing messages,
we may want to let the user postpone that (maybe notmuch new --reindex
or something).  I also think we should have "unstable" features for
things that are under development and may change in
non-backwards-compatible ways.  This would be specifically targeted at
developers, and developers would have to opt in to these unstable
features.  But the goal would always be to stabilize them and make
them standard features that are automatically upgraded to.

> Best wishes
> 
> Mark
> 
> >      status = notmuch_database_upgrade (notmuch, NULL, NULL);
> >      if (status) {
> >  	notmuch_database_close(notmuch);
> > @@ -619,6 +656,80 @@ _notmuch_database_ensure_writable (notmuch_database_t *notmuch)
> >      return NOTMUCH_STATUS_SUCCESS;
> >  }
> >  
> > +/* Parse a database features string from the given database version.
> > + *
> > + * For version < 3, this ignores the features string and returns a
> > + * hard-coded set of features.
> > + *
> > + * If there are unrecognized features that are required to open the
> > + * database in mode (which should be 'r' or 'w'), return a
> > + * comma-separated list of unrecognized but required features in
> > + * *incompat_out, which will be allocated from ctx.
> > + */
> > +static unsigned int
> > +_parse_features (const void *ctx, const char *features, unsigned int version,
> > +		 char mode, char **incompat_out)
> > +{
> > +    unsigned int res = 0, namelen, i;
> > +    size_t llen = 0;
> > +    const char *flags;
> > +
> > +    /* Prior to database version 3, features were implied by the
> > +     * version number. */
> > +    if (version == 0)
> > +	return NOTMUCH_FEATURES_V0;
> > +    else if (version == 1)
> > +	return NOTMUCH_FEATURES_V1;
> > +    else if (version == 2)
> > +	return NOTMUCH_FEATURES_V2;
> > +
> > +    /* Parse the features string */
> > +    while ((features = strtok_len_c (features + llen, "\n", &llen)) != NULL) {
> > +	flags = strchr (features, '\t');
> > +	if (! flags || flags > features + llen)
> > +	    continue;
> > +	namelen = flags - features;
> > +
> > +	for (i = 0; i < ARRAY_SIZE (feature_names); ++i) {
> > +	    if (strlen (feature_names[i].name) == namelen &&
> > +		strncmp (feature_names[i].name, features, namelen) == 0) {
> > +		res |= feature_names[i].value;
> > +		break;
> > +	    }
> > +	}
> > +
> > +	if (i == ARRAY_SIZE (feature_names)) {
> > +	    /* Unrecognized feature */
> > +	    const char *have = strchr (flags, mode);
> > +	    if (have && have < features + llen) {
> > +		/* This feature is required to access this database in
> > +		 * 'mode', but we don't understand it. */
> > +		if (! *incompat_out)
> > +		    *incompat_out = talloc_strdup (ctx, "");
> > +		*incompat_out = talloc_asprintf_append_buffer (
> > +		    *incompat_out, "%s%.*s", **incompat_out ? ", " : "",
> > +		    namelen, features);
> > +	    }
> > +	}
> > +    }
> > +
> > +    return res;
> > +}
> > +
> > +static char *
> > +_print_features (const void *ctx, unsigned int features)
> > +{
> > +    unsigned int i;
> > +    char *res = talloc_strdup (ctx, "");
> > +
> > +    for (i = 0; i < ARRAY_SIZE (feature_names); ++i)
> > +	if (features & feature_names[i].value)
> > +	    res = talloc_asprintf_append_buffer (
> > +		res, "%s\t%s\n", feature_names[i].name, feature_names[i].flags);
> > +
> > +    return res;
> > +}
> > +
> >  notmuch_status_t
> >  notmuch_database_open (const char *path,
> >  		       notmuch_database_mode_t mode,
> > @@ -627,7 +738,7 @@ notmuch_database_open (const char *path,
> >      notmuch_status_t status = NOTMUCH_STATUS_SUCCESS;
> >      void *local = talloc_new (NULL);
> >      notmuch_database_t *notmuch = NULL;
> > -    char *notmuch_path, *xapian_path;
> > +    char *notmuch_path, *xapian_path, *incompat_features;
> >      struct stat st;
> >      int err;
> >      unsigned int i, version;
> > @@ -686,39 +797,51 @@ notmuch_database_open (const char *path,
> >  	if (mode == NOTMUCH_DATABASE_MODE_READ_WRITE) {
> >  	    notmuch->xapian_db = new Xapian::WritableDatabase (xapian_path,
> >  							       Xapian::DB_CREATE_OR_OPEN);
> > -	    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_destroy (notmuch);
> > -		notmuch = NULL;
> > -		status = NOTMUCH_STATUS_FILE_ERROR;
> > -		goto DONE;
> > -	    }
> > -
> > -	    if (version < NOTMUCH_DATABASE_VERSION)
> > -		notmuch->needs_upgrade = TRUE;
> >  	} else {
> >  	    notmuch->xapian_db = new Xapian::Database (xapian_path);
> > -	    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);
> > -	    }
> >  	}
> >  
> > +	/* Check version.  As of database version 3, we represent
> > +	 * changes in terms of features, so assume a version bump
> > +	 * means a dramatically incompatible change. */
> > +	version = notmuch_database_get_version (notmuch);
> > +	if (version > NOTMUCH_DATABASE_VERSION) {
> > +	    fprintf (stderr,
> > +		     "Error: Notmuch database at %s\n"
> > +		     "       has a newer database format version (%u) than supported by this\n"
> > +		     "       version of notmuch (%u).\n",
> > +		     notmuch_path, version, NOTMUCH_DATABASE_VERSION);
> > +	    notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
> > +	    notmuch_database_destroy (notmuch);
> > +	    notmuch = NULL;
> > +	    status = NOTMUCH_STATUS_FILE_ERROR;
> > +	    goto DONE;
> > +	}
> > +
> > +	/* Check features. */
> > +	incompat_features = NULL;
> > +	notmuch->features = _parse_features (
> > +	    local, notmuch->xapian_db->get_metadata ("features").c_str (),
> > +	    version, mode == NOTMUCH_DATABASE_MODE_READ_WRITE ? 'w' : 'r',
> > +	    &incompat_features);
> > +	if (incompat_features) {
> > +	    fprintf (stderr,
> > +		     "Error: Notmuch database at %s\n"
> > +		     "       requires features (%s)\n"
> > +		     "       not supported by this version of notmuch.\n",
> > +		     notmuch_path, incompat_features);
> > +	    notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
> > +	    notmuch_database_destroy (notmuch);
> > +	    notmuch = NULL;
> > +	    status = NOTMUCH_STATUS_FILE_ERROR;
> > +	    goto DONE;
> > +	}
> > +
> > +	/* Do we want an upgrade? */
> > +	if (mode == NOTMUCH_DATABASE_MODE_READ_WRITE &&
> > +	    NOTMUCH_FEATURES_CURRENT & ~notmuch->features)
> > +	    notmuch->needs_upgrade = TRUE;
> > +
> >  	notmuch->last_doc_id = notmuch->xapian_db->get_lastdocid ();
> >  	last_thread_id = notmuch->xapian_db->get_metadata ("last_thread_id");
> >  	if (last_thread_id.empty ()) {
> > @@ -1077,6 +1200,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
> >  						   double progress),
> >  			  void *closure)
> >  {
> > +    void *local = talloc_new (NULL);
> >      Xapian::WritableDatabase *db;
> >      struct sigaction action;
> >      struct itimerval timerval;
> > @@ -1226,6 +1350,8 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
> >  	notmuch_query_destroy (query);
> >      }
> >  
> > +    notmuch->features |= NOTMUCH_FEATURES_CURRENT;
> > +    db->set_metadata ("features", _print_features (local, notmuch->features));
> >      db->set_metadata ("version", STRINGIFY (NOTMUCH_DATABASE_VERSION));
> >      db->flush ();
> >  
> > @@ -1302,6 +1428,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
> >  	sigaction (SIGALRM, &action, NULL);
> >      }
> >  
> > +    talloc_free (local);
> >      return NOTMUCH_STATUS_SUCCESS;
> >  }
> >