Bug 754780 - If Tb 10 and Tb 11 is skipped, Gloda Scheme change is not correctly detected and gloda error is reported to Error Console by Tb 12 or newer, then Global Search doesn't work. tests. r+a=Standard8
authorAndrew Sutherland <asutherland@asutherland.org>
Fri, 25 May 2012 11:25:29 -0700
changeset 11356 01303a6f3d9b407f5df7eb37af6c19f97daa3765
parent 11355 166d519fc95e0d504a892409e5a8eb34e6e43747
child 11357 82e2188d2a1a562825502341c09bac9ce4678590
push idunknown
push userunknown
push dateunknown
bugs754780
Bug 754780 - If Tb 10 and Tb 11 is skipped, Gloda Scheme change is not correctly detected and gloda error is reported to Error Console by Tb 12 or newer, then Global Search doesn't work. tests. r+a=Standard8
mailnews/db/gloda/test/unit/test_nuke_migration.js
mailnews/db/gloda/test/unit/test_nuke_migration_from_future.js
mailnews/db/gloda/test/unit/xpcshell.ini
new file mode 100644
--- /dev/null
+++ b/mailnews/db/gloda/test/unit/test_nuke_migration.js
@@ -0,0 +1,71 @@
+/**
+ * Atypical gloda unit test that tests nuke migration.  Gloda is not designed
+ * to be shutdown and started up again in the same process lifetime.  It tries
+ * to be clever with caching accessors that clobber themselves out of existence
+ * which are hard to make come back to life, and probably other things.
+ *
+ * So what we do is create a global-messages-db.sqlite with an unacceptably
+ * old schema version before tickling gloda to startup.  If gloda comes up
+ * with a database connection and it has the right schema version, we declare
+ * that gloda has successfully loaded.  Our only historical screw-up here was
+ * very blatant (and was actually a result of trying to avoid complexity in
+ * the nuke path! oh the irony!) so we don't need to get all hardcore.
+ **/
+
+// we need the directory service
+load("../../../../resources/mailDirService.js");
+
+/**
+ * The DB version to use.  We set this as a non-const variable so that
+ * test_nuke_migration_from_future.js can change it.
+ */
+var BAD_DB_VERSION_TO_USE = 2;
+
+/**
+ * Synchronously create and close the out-of-date database.  Because we are
+ * only using synchronous APIs, we know everything is in fact dead.  GC being
+ * what it is, the various C++ objects will probably stay alive through the
+ * next test, but will be inert because we have closed the database.
+ */
+function make_out_of_date_database() {
+    // Get the path to our global database
+    var dirService = Cc["@mozilla.org/file/directory_service;1"].
+                     getService(Ci.nsIProperties);
+    var dbFile = dirService.get("ProfD", Ci.nsIFile);
+    dbFile.append("global-messages-db.sqlite");
+
+    // Get the storage (sqlite) service
+    var dbService = Cc["@mozilla.org/storage/service;1"].
+                    getService(Ci.mozIStorageService);
+    // Create the database
+    var dbConnection = dbService.openUnsharedDatabase(dbFile);
+    dbConnection.schemaVersion = BAD_DB_VERSION_TO_USE;
+
+    // Close the database (will throw if there's a problem closing)
+    dbConnection.close();
+}
+
+// some copied and pasted preference setup from glodaTestHelper that is
+// appropriate here.
+const gPrefs = Cc["@mozilla.org/preferences-service;1"]
+                 .getService(Ci.nsIPrefBranch);
+// yes to indexing
+gPrefs.setBoolPref("mailnews.database.global.indexer.enabled", true);
+// no to a sweep we don't control
+gPrefs.setBoolPref("mailnews.database.global.indexer.perform_initial_sweep",
+    false);
+// yes to debug output
+gPrefs.setBoolPref("mailnews.database.global.logging.dump", true);
+
+function run_test() {
+
+  // - make the old database
+  make_out_of_date_database();
+
+  // - tickle gloda
+  // public.js loads gloda.js which self-initializes and initializes the datastore
+  Components.utils.import("resource:///modules/gloda/public.js");
+  Components.utils.import("resource:///modules/gloda/datastore.js");
+
+  do_check_neq(GlodaDatastore.asyncConnection, null);
+}
new file mode 100644
--- /dev/null
+++ b/mailnews/db/gloda/test/unit/test_nuke_migration_from_future.js
@@ -0,0 +1,11 @@
+/**
+ * There are actually two ways the nuke migration can be invoked.  From
+ * a database too far from the future, and too far from the past.  This
+ * one is the future one.  We must keep ourselves safe from time-traveling
+ * grandchildren!
+ **/
+
+load("test_nuke_migration.js");
+
+// pick something so far forward it will never get used!
+BAD_DB_VERSION_TO_USE = 100000000;
--- a/mailnews/db/gloda/test/unit/xpcshell.ini
+++ b/mailnews/db/gloda/test/unit/xpcshell.ini
@@ -20,14 +20,16 @@ tail = tail_gloda.js
 [test_index_messages_local.js]
 [test_index_sweep_folder.js]
 [test_intl.js]
 [test_migration.js]
 [test_mime_attachments_size.js]
 [test_mime_emitter.js]
 [test_msg_search.js]
 [test_noun_mimetype.js]
+[test_nuke_migration.js]
+[test_nuke_migration_from_future.js]
 [test_query_core.js]
 [test_query_messages_imap_offline.js]
 [test_query_messages_imap_online.js]
 [test_query_messages_imap_online_to_offline.js]
 [test_query_messages_local.js]
 [test_startup_offline.js]