7f/2c20d56e23d2921b7c6b378707ad52f5357540

   1 Return-Path: <jani@nikula.org>\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 1AAB6431FBD\r
   6         for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 06:59:27 -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.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 AbtrUtCZGzGB for <notmuch@notmuchmail.org>;\r
  16         Sat, 25 Jan 2014 06:59:18 -0800 (PST)\r
  17 Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com\r
  18  [74.125.83.43])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
  19  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
  20  404BD431FBC    for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 06:59:18 -0800\r
  21  (PST)\r
  22 Received: by mail-ee0-f43.google.com with SMTP id c41so1458527eek.2\r
  23         for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 06:59:15 -0800 (PST)\r
  24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  25         d=1e100.net; s=20130820;\r
  26         h=x-gm-message-state:from:to:subject:in-reply-to:references\r
  27         :user-agent:date:message-id:mime-version:content-type;\r
  28         bh=WzV0sKZ1Z9hOTB5VtkyP0My7aoGQpE+PLXk/C+Rd/vU=;\r
  29         b=aBLjonhI2BtBHTbRCkD3V3EbDxvl9np1jLrJpJO6+1XNTRhSs5C8lhJQK5SlmWsuUm\r
  30         4rz+kxQEEKPMJ1bDfW2U29gXx0izbnRPpcA+E0O6lyRNiygIwwZT94WOEs9EdHXz53KR\r
  31         P3fHQYL+Nc6nqczA5yMJi2J4mnwBpZsQrbd7WSRmEykyBHCPsOLDIH9oiEpubN4g1X1I\r
  32         Enx5mchLHBkdEHRsqum3o2WAyarn4uNWNn4hlJtGhepCKrlPt0N6mZE2Q4ze5MOq2imZ\r
  33         JbVJQcpJuCSU2Vu2hpfF7ZUUbyjFb/9uzx2qFVWu3MdplDBJ9G5gOo057ZOcxqJ/Te8O\r
  34         /C2Q==\r
  35 X-Gm-Message-State:\r
  36  ALoCoQm1eLbJSoTQmCpuF9nW0ZD8mwJKukirxEIDtrjquShccWQJ+uBb5OzC0RbgRm7ooocBcCYk\r
  37 X-Received: by 10.15.43.10 with SMTP id w10mr17785277eev.13.1390661955569;\r
  38         Sat, 25 Jan 2014 06:59:15 -0800 (PST)\r
  39 Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi.\r
  40         [88.195.111.91])\r
  41         by mx.google.com with ESMTPSA id w4sm16827820eef.20.2014.01.25.06.59.13\r
  42         for <multiple recipients>\r
  43         (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
  44         Sat, 25 Jan 2014 06:59:14 -0800 (PST)\r
  45 From: Jani Nikula <jani@nikula.org>\r
  46 To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
  47 Subject: automatic database upgrades (was: Re: [PATCH 0/7] cli: notmuch new\r
  48         improvements)\r
  49 In-Reply-To: <87ppnga21o.fsf@qmul.ac.uk>\r
  50 References: <cover.1390163335.git.jani@nikula.org> <87ppnga21o.fsf@qmul.ac.uk>\r
  51 User-Agent: Notmuch/0.17+44~ge3b4cd9 (http://notmuchmail.org) Emacs/24.3.1\r
  52         (x86_64-pc-linux-gnu)\r
  53 Date: Sat, 25 Jan 2014 16:59:12 +0200\r
  54 Message-ID: <87lhy4f6pr.fsf@nikula.org>\r
  55 MIME-Version: 1.0\r
  56 Content-Type: text/plain\r
  57 X-BeenThere: notmuch@notmuchmail.org\r
  58 X-Mailman-Version: 2.1.13\r
  59 Precedence: list\r
  60 List-Id: "Use and development of the notmuch mail system."\r
  61         <notmuch.notmuchmail.org>\r
  62 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  63         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  64 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  65 List-Post: <mailto:notmuch@notmuchmail.org>\r
  66 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  67 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  68         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  69 X-List-Received-Date: Sat, 25 Jan 2014 14:59:27 -0000\r
  70 \r
  71 On Sat, 25 Jan 2014, Mark Walters <markwalters1009@gmail.com> wrote:\r
  72 > This series LGTM.\r
  73 \r
  74 Hi Mark, thanks for the review!\r
  75 \r
  76 > I do now recall there was some discussion on irc about the automatic\r
  77 > database upgrade: it would be good to have that documented but the\r
  78 > consensus was to do it, so +1 from me.\r
  79 \r
  80 Here's some summary, as promised. Please bear in mind that the\r
  81 discussion is pretty much irrelevant to this particular patch\r
  82 series. (We might discuss whether a warning about upgrade should be\r
  83 printed to stderr also with --quiet, but IMHO that can be a follow-up\r
  84 patch.)\r
  85 \r
  86 A database upgrade is required when the user upgrades to a new version\r
  87 of notmuch that has a modified database schema. See\r
  88 id:cover.1389304779.git.jani@nikula.org for an example of a proposed\r
  89 database change.\r
  90 \r
  91 A database upgrade is a rare event. Most of the time, it's okay to go\r
  92 back and forth with notmuch versions on the same database, but a\r
  93 database upgrade is an irreversible process after which the user must\r
  94 use the new version of notmuch. To go back requires a full rebuild of\r
  95 the database.\r
  96 \r
  97 We don't have recent experience with the database upgrades. The last\r
  98 time it happened was before notmuch 0.1 (yes, 0.1) was released, when\r
  99 the whole upgrade mechanism was introduced:\r
 100 \r
 101 commit 909f52bd8c4bdfa11cd3e75e3d0959e0293689bd\r
 102 Author: Carl Worth <cworth@cworth.org>\r
 103 Date:   Thu Jan 7 18:26:31 2010 -0800\r
 104 \r
 105     lib: Implement versioning in the database and provide upgrade function.\r
 106 \r
 107 Some of the points in favor of requiring manual intervention (such as\r
 108 running 'notmuch new --upgrade' or a new command 'notmuch upgrade')\r
 109 before upgrading the database:\r
 110 \r
 111 * The database upgrade is an irreversible process. The user should have\r
 112   a chance to decide whether to go ahead with that. You can't go back to\r
 113   the old notmuch and database version without rebuilding the database.\r
 114 \r
 115 * The user should be given the chance to make backups first in case\r
 116   something goes wrong.\r
 117 \r
 118 * The database upgrade might take a long time for large databases. The\r
 119   user should be able to choose when to go ahead with that.\r
 120 \r
 121 Some of the points in favor of upgrading automatically:\r
 122 \r
 123 * cworth: "One potential concern is that [requiring manual intervention]\r
 124   effectively breaks notmuch until the user intervenese and runs this\r
 125   new command. So that can complicate things for any interface that sits\r
 126   on top of notmuch."\r
 127 \r
 128 * cworth: "In general, I'm often frustrated with programs that say "I\r
 129   cannot continue until you run command <foo>.". If command <foo> needs\r
 130   to be run, and the software knows it, why doesn't it just run it\r
 131   itself? [...] So a message like "Run 'notmuch upgrade'" seems it could\r
 132   corrode the user's trust in notmuch to maintain its own state."\r
 133 \r
 134 * There are people who run notmuch new non-interactively. There's no\r
 135   easy answer to handling that if manual intervention is required.\r
 136 \r
 137 * It should always be okay to kill the upgrade, and continue at a later\r
 138   time, in case it takes too long.\r
 139 \r
 140 Reading the logs again, I'm not so confident about us reaching a\r
 141 concensus. Maybe it was just me changing my mind during the course of\r
 142 the discussion... so we can try to reach concensus here.\r
 143 \r
 144 \r
 145 BR,\r
 146 Jani.\r