b9/fcd6486156fc8877aa822053786502a4ffd8bc

   1 Return-Path: <david@tethera.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 4A145431FDA\r
   6         for <notmuch@notmuchmail.org>; Wed, 31 Dec 2014 00:28:14 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id UuFgWwNrL1Q8 for <notmuch@notmuchmail.org>;\r
  16         Wed, 31 Dec 2014 00:28:11 -0800 (PST)\r
  17 Received: from yantan.tethera.net (yantan.tethera.net [199.188.72.155])\r
  18         (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id 1B16D431FCB\r
  21         for <notmuch@notmuchmail.org>; Wed, 31 Dec 2014 00:28:11 -0800 (PST)\r
  22 Received: from remotemail by yantan.tethera.net with local (Exim 4.80)\r
  23         (envelope-from <david@tethera.net>)\r
  24         id 1Y6EdV-0004Uq-Pu; Wed, 31 Dec 2014 04:28:09 -0400\r
  25 Received: (nullmailer pid 3100 invoked by uid 1000); Wed, 31 Dec 2014\r
  26         08:28:04 -0000\r
  27 From: David Bremner <david@tethera.net>\r
  28 To: Gaute Hope <eg@gaute.vetsj.com>, notmuch <notmuch@notmuchmail.org>\r
  29 Subject: Re: DatabaseModifiedErrors causing troubles\r
  30 In-Reply-To:\r
  31  <CABKe4MvEdcsq8BZ-vq6R0Vnw87zEgBvqW_2F-Wysf5GNchqweg@mail.gmail.com>\r
  32 References:\r
  33  <CABKe4MvEdcsq8BZ-vq6R0Vnw87zEgBvqW_2F-Wysf5GNchqweg@mail.gmail.com>\r
  34 User-Agent: Notmuch/0.19+7~g5d7f7a6 (http://notmuchmail.org) Emacs/24.4.1\r
  35         (x86_64-pc-linux-gnu)\r
  36 Date: Wed, 31 Dec 2014 09:28:04 +0100\r
  37 Message-ID: <87bnmkgr57.fsf@maritornes.cs.unb.ca>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: text/plain\r
  40 X-BeenThere: notmuch@notmuchmail.org\r
  41 X-Mailman-Version: 2.1.13\r
  42 Precedence: list\r
  43 List-Id: "Use and development of the notmuch mail system."\r
  44         <notmuch.notmuchmail.org>\r
  45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  47 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  48 List-Post: <mailto:notmuch@notmuchmail.org>\r
  49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  52 X-List-Received-Date: Wed, 31 Dec 2014 08:28:14 -0000\r
  53 \r
  54 Gaute Hope <eg@gaute.vetsj.com> writes:\r
  55 \r
  56 > I can work around this by checking for a NULL pointer returned from\r
  57 > notmuch_query_search_threads () and re-open the database\r
  58 > (notmuch_database_close () -> notmuch_database_open ()). But I have no\r
  59 > way of knowing programatically if this really is the error that has\r
  60 > happened. There should be some way of propagating the error\r
  61 > information or (even better for my case; for notmuch to reopen the\r
  62 > database), one option is the Gmime way of passing an pointer to an\r
  63 > error structure that is filled up by the notmuch interface function.\r
  64 \r
  65 Hi Gaute;\r
  66 \r
  67 Sorry this sequence of postings of yours kindof fell down a well. In\r
  68 general there seems to be not very much enthusiasm for the GError\r
  69 solution.  We can do something less fancy with the series at\r
  70 \r
  71            id:1419788030-10567-2-git-send-email-david@tethera.net\r
  72 \r
  73 In particular id:1419788030-10567-6-git-send-email-david@tethera.net\r
  74 replaces the printfs with saving to a status string accessible from\r
  75 notmuch_database_t.\r
  76 \r
  77 I _think_ this could solve your problem, although doing strcmp on error\r
  78 message might not be ideal. Overall this is much less api breakage\r
  79 (only open and create need to be wrapped).\r
  80 \r
  81 We could also consider really updating the api for those NULL returning\r
  82 functions, but it seems less bad to me than the count functions updated\r
  83 in this series\r
  84 \r
  85    id:1419971380-10307-2-git-send-email-david@tethera.net\r
  86 \r
  87 Let me know what you think,\r
  88 \r
  89 David\r