Re: DatabaseModifiedErrors causing troubles

diff --git a/b9/fcd6486156fc8877aa822053786502a4ffd8bc b/b9/fcd6486156fc8877aa822053786502a4ffd8bc
new file mode 100644 (file)
index 0000000..c7e6bec
--- /dev/null
+++ b/b9/fcd6486156fc8877aa822053786502a4ffd8bc
@@ -0,0 +1,89 @@
+Return-Path: <david@tethera.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 4A145431FDA\r
+       for <notmuch@notmuchmail.org>; Wed, 31 Dec 2014 00:28:14 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id UuFgWwNrL1Q8 for <notmuch@notmuchmail.org>;\r
+       Wed, 31 Dec 2014 00:28:11 -0800 (PST)\r
+Received: from yantan.tethera.net (yantan.tethera.net [199.188.72.155])\r
+       (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 1B16D431FCB\r
+       for <notmuch@notmuchmail.org>; Wed, 31 Dec 2014 00:28:11 -0800 (PST)\r
+Received: from remotemail by yantan.tethera.net with local (Exim 4.80)\r
+       (envelope-from <david@tethera.net>)\r
+       id 1Y6EdV-0004Uq-Pu; Wed, 31 Dec 2014 04:28:09 -0400\r
+Received: (nullmailer pid 3100 invoked by uid 1000); Wed, 31 Dec 2014\r
+       08:28:04 -0000\r
+From: David Bremner <david@tethera.net>\r
+To: Gaute Hope <eg@gaute.vetsj.com>, notmuch <notmuch@notmuchmail.org>\r
+Subject: Re: DatabaseModifiedErrors causing troubles\r
+In-Reply-To:\r
+ <CABKe4MvEdcsq8BZ-vq6R0Vnw87zEgBvqW_2F-Wysf5GNchqweg@mail.gmail.com>\r
+References:\r
+ <CABKe4MvEdcsq8BZ-vq6R0Vnw87zEgBvqW_2F-Wysf5GNchqweg@mail.gmail.com>\r
+User-Agent: Notmuch/0.19+7~g5d7f7a6 (http://notmuchmail.org) Emacs/24.4.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Wed, 31 Dec 2014 09:28:04 +0100\r
+Message-ID: <87bnmkgr57.fsf@maritornes.cs.unb.ca>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 31 Dec 2014 08:28:14 -0000\r
+\r
+Gaute Hope <eg@gaute.vetsj.com> writes:\r
+\r
+> I can work around this by checking for a NULL pointer returned from\r
+> notmuch_query_search_threads () and re-open the database\r
+> (notmuch_database_close () -> notmuch_database_open ()). But I have no\r
+> way of knowing programatically if this really is the error that has\r
+> happened. There should be some way of propagating the error\r
+> information or (even better for my case; for notmuch to reopen the\r
+> database), one option is the Gmime way of passing an pointer to an\r
+> error structure that is filled up by the notmuch interface function.\r
+\r
+Hi Gaute;\r
+\r
+Sorry this sequence of postings of yours kindof fell down a well. In\r
+general there seems to be not very much enthusiasm for the GError\r
+solution.  We can do something less fancy with the series at\r
+\r
+           id:1419788030-10567-2-git-send-email-david@tethera.net\r
+\r
+In particular id:1419788030-10567-6-git-send-email-david@tethera.net\r
+replaces the printfs with saving to a status string accessible from\r
+notmuch_database_t.\r
+\r
+I _think_ this could solve your problem, although doing strcmp on error\r
+message might not be ideal. Overall this is much less api breakage\r
+(only open and create need to be wrapped).\r
+\r
+We could also consider really updating the api for those NULL returning\r
+functions, but it seems less bad to me than the count functions updated\r
+in this series\r
+\r
+   id:1419971380-10307-2-git-send-email-david@tethera.net\r
+\r
+Let me know what you think,\r
+\r
+David\r