Re: DatabaseModifiedErrors causing troubles
authorGaute Hope <eg@gaute.vetsj.com>
Sat, 17 Jan 2015 11:18:43 +0000 (11:18 +0000)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:47:27 +0000 (14:47 -0700)
f5/c026175fa678c3984c8a67028653974d34015e [new file with mode: 0644]

diff --git a/f5/c026175fa678c3984c8a67028653974d34015e b/f5/c026175fa678c3984c8a67028653974d34015e
new file mode 100644 (file)
index 0000000..21288bf
--- /dev/null
@@ -0,0 +1,126 @@
+Return-Path: <eg@gaute.vetsj.com>\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 353BF431FD9\r
+       for <notmuch@notmuchmail.org>; Sat, 17 Jan 2015 03:17:50 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 1.738\r
+X-Spam-Level: *\r
+X-Spam-Status: No, score=1.738 tagged_above=-999 required=5\r
+       tests=[DNS_FROM_AHBL_RHSBL=2.438, RCVD_IN_DNSWL_LOW=-0.7]\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 0BvgIaEH7DcM for <notmuch@notmuchmail.org>;\r
+       Sat, 17 Jan 2015 03:17:46 -0800 (PST)\r
+Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com\r
+       [209.85.217.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 84344431FAF\r
+       for <notmuch@notmuchmail.org>; Sat, 17 Jan 2015 03:17:46 -0800 (PST)\r
+Received: by mail-lb0-f170.google.com with SMTP id 10so22084944lbg.1\r
+       for <notmuch@notmuchmail.org>; Sat, 17 Jan 2015 03:17:45 -0800 (PST)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+       d=1e100.net; s=20130820;\r
+       h=x-gm-message-state:date:from:subject:to:references:in-reply-to\r
+       :user-agent:message-id:mime-version:content-type\r
+       :content-transfer-encoding;\r
+       bh=/cpM2H3vRNph4jheM83SzNpW9w/f6olBC86vtSM5IBU=;\r
+       b=KaGsKHon/rBj0zS1OxUAwuzuLz01Q5bCvErFKfu0EiW6qK59NGa1frlBN/P6cQQI9w\r
+       W0ws0zH9AtA6gQRNuQxz4loTAm2mxx7MiqNiUYKL4LwSXEUVSSLph/QrNa1q5YVfaPaE\r
+       naGRywQhwuKoknDD6mb2AZLpANO+tmD7eqF31tiH72747QYCo7nKR+bibt0wWG4CX/VC\r
+       /BSeA1cabkVt5Vk7s+F2wW8fVqlnUGwijMdJmjIINeP8F4qIfU/xTaqOHenErA1+zo9f\r
+       nZTilvfp7CbN31rFRYGrsPa5xoUrQ1ESSYs59TTWRMWnmyx5vJupG688NEtH0caijdu8\r
+       zkcw==\r
+X-Gm-Message-State:\r
+ ALoCoQnWdwmY5iVUz0sQAWF7n96OsaoK86VQMrpXsSreuJaMROQZu+oVahEZLFR5DVq3euugJkYP\r
+X-Received: by 10.112.172.194 with SMTP id be2mr20531561lbc.53.1421493465077; \r
+       Sat, 17 Jan 2015 03:17:45 -0800 (PST)\r
+Received: from localhost (c2774BF51.dhcp.as2116.net. [81.191.116.39])\r
+       by mx.google.com with ESMTPSA id p10sm2065524lap.10.2015.01.17.03.17.43\r
+       (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\r
+       Sat, 17 Jan 2015 03:17:44 -0800 (PST)\r
+Date: Sat, 17 Jan 2015 11:18:43 +0000\r
+From: Gaute Hope <eg@gaute.vetsj.com>\r
+Subject: Re: DatabaseModifiedErrors causing troubles\r
+To: David Bremner <david@tethera.net>, notmuch <notmuch@notmuchmail.org>\r
+References:\r
+ <CABKe4MvEdcsq8BZ-vq6R0Vnw87zEgBvqW_2F-Wysf5GNchqweg@mail.gmail.com>\r
+       <87bnmkgr57.fsf@maritornes.cs.unb.ca>\r
+In-Reply-To: <87bnmkgr57.fsf@maritornes.cs.unb.ca>\r
+User-Agent: astroid/vv0.1-42-ge9d4344b (https://github.com/gauteh/astroid)\r
+Message-Id: <1421493070-astroid-1-4x8pflg7mc-1327@strange>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8; format=flowed\r
+Content-Transfer-Encoding: quoted-printable\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 11:17:50 -0000\r
+\r
+Excerpts from David Bremner's message of December 31, 2014 9:28:\r
+> Gaute Hope <eg@gaute.vetsj.com> writes:\r
+>=20\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
+>=20\r
+> Hi Gaute;\r
+>=20\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
+>=20\r
+>            id:1419788030-10567-2-git-send-email-david@tethera.net\r
+>=20\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
+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
+Best regards, Gaute\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
+>=20\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
+>=20\r
+>    id:1419971380-10307-2-git-send-email-david@tethera.net\r
+>=20\r
+> Let me know what you think,\r
+>=20\r
+> David\r
+>=20\r
+=\r