Re: DatabaseModifiedErrors causing troubles
authorDavid Bremner <david@tethera.net>
Sat, 17 Jan 2015 12:29:31 +0000 (13:29 +0100)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:47:27 +0000 (14:47 -0700)
4a/f99ca7fd70c8cf99954e80c7a8e6924a44d661 [new file with mode: 0644]

diff --git a/4a/f99ca7fd70c8cf99954e80c7a8e6924a44d661 b/4a/f99ca7fd70c8cf99954e80c7a8e6924a44d661
new file mode 100644 (file)
index 0000000..44834f0
--- /dev/null
@@ -0,0 +1,87 @@
+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 02645431FC2\r
+       for <notmuch@notmuchmail.org>; Sat, 17 Jan 2015 04:29:41 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 2.438\r
+X-Spam-Level: **\r
+X-Spam-Status: No, score=2.438 tagged_above=-999 required=5\r
+       tests=[DNS_FROM_AHBL_RHSBL=2.438] 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 8riIKuVUO6ph for <notmuch@notmuchmail.org>;\r
+       Sat, 17 Jan 2015 04:29:37 -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 CC636431FAF\r
+       for <notmuch@notmuchmail.org>; Sat, 17 Jan 2015 04:29:37 -0800 (PST)\r
+Received: from remotemail by yantan.tethera.net with local (Exim 4.80)\r
+       (envelope-from <david@tethera.net>)\r
+       id 1YCSVU-0006tU-RM; Sat, 17 Jan 2015 08:29:36 -0400\r
+Received: (nullmailer pid 25526 invoked by uid 1000); Sat, 17 Jan 2015\r
+       12:29:31 -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: <1421493070-astroid-1-4x8pflg7mc-1327@strange>\r
+References:\r
+ <CABKe4MvEdcsq8BZ-vq6R0Vnw87zEgBvqW_2F-Wysf5GNchqweg@mail.gmail.com>\r
+       <87bnmkgr57.fsf@maritornes.cs.unb.ca>\r
+       <1421493070-astroid-1-4x8pflg7mc-1327@strange>\r
+User-Agent: Notmuch/0.19+21~g71fb37d (http://notmuchmail.org) Emacs/24.4.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Sat, 17 Jan 2015 13:29:31 +0100\r
+Message-ID: <87fvb9bnf8.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: Sat, 17 Jan 2015 12:29:41 -0000\r
+\r
+Gaute Hope <eg@gaute.vetsj.com> writes:\r
+\r
+>\r
+> Hi David,\r
+>\r
+> Would it be possible with an error code that I could compare against in\r
+> stead? It would then work a bit like a global instance of the gmime\r
+> error. It could even be a preparation step against a gmime-error-style\r
+> solution in the far future.\r
+>\r
+> I am sure you know all the bad reasons for using a strcmp with strings\r
+> such as small (subtle) changes making them useless or future\r
+> localization of notmuch. This solution is in my opinion worse than the\r
+> current situation, it will lock things in and create problems for future\r
+> API compatability and application maintainers. I would rather wait for\r
+> or spend some time on a more general solution.\r
+\r
+I don't agree it's worse than the current situation but I take your\r
+point it isn't ideal.  We could do some kind "errno" in the database\r
+structure.  I think there are not that many functions with this\r
+unhelpful error return type. Based on a scan of notmuch.h, I see\r
+\r
+notmuch_query_search_threads\r
+notmuch_query_search_messages\r
+\r
+and the two count functions that I already posted API breaking patches\r
+for.  It might be better just to update the API (either adding versions\r
+with error returns, or just forcing people to change) for these\r
+functions.  Otherwise we have two different ways of returning status\r
+codes, and the "errno" is only used some of the time.\r
+\r
+d\r
+\r