--- /dev/null
+Return-Path: <jani@nikula.org>\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 1AAB6431FBD\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 06:59:27 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 AbtrUtCZGzGB for <notmuch@notmuchmail.org>;\r
+ Sat, 25 Jan 2014 06:59:18 -0800 (PST)\r
+Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com\r
+ [74.125.83.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client\r
+ certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
+ 404BD431FBC for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 06:59:18 -0800\r
+ (PST)\r
+Received: by mail-ee0-f43.google.com with SMTP id c41so1458527eek.2\r
+ for <notmuch@notmuchmail.org>; Sat, 25 Jan 2014 06:59:15 -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:from:to:subject:in-reply-to:references\r
+ :user-agent:date:message-id:mime-version:content-type;\r
+ bh=WzV0sKZ1Z9hOTB5VtkyP0My7aoGQpE+PLXk/C+Rd/vU=;\r
+ b=aBLjonhI2BtBHTbRCkD3V3EbDxvl9np1jLrJpJO6+1XNTRhSs5C8lhJQK5SlmWsuUm\r
+ 4rz+kxQEEKPMJ1bDfW2U29gXx0izbnRPpcA+E0O6lyRNiygIwwZT94WOEs9EdHXz53KR\r
+ P3fHQYL+Nc6nqczA5yMJi2J4mnwBpZsQrbd7WSRmEykyBHCPsOLDIH9oiEpubN4g1X1I\r
+ Enx5mchLHBkdEHRsqum3o2WAyarn4uNWNn4hlJtGhepCKrlPt0N6mZE2Q4ze5MOq2imZ\r
+ JbVJQcpJuCSU2Vu2hpfF7ZUUbyjFb/9uzx2qFVWu3MdplDBJ9G5gOo057ZOcxqJ/Te8O\r
+ /C2Q==\r
+X-Gm-Message-State:\r
+ ALoCoQm1eLbJSoTQmCpuF9nW0ZD8mwJKukirxEIDtrjquShccWQJ+uBb5OzC0RbgRm7ooocBcCYk\r
+X-Received: by 10.15.43.10 with SMTP id w10mr17785277eev.13.1390661955569;\r
+ Sat, 25 Jan 2014 06:59:15 -0800 (PST)\r
+Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi.\r
+ [88.195.111.91])\r
+ by mx.google.com with ESMTPSA id w4sm16827820eef.20.2014.01.25.06.59.13\r
+ for <multiple recipients>\r
+ (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
+ Sat, 25 Jan 2014 06:59:14 -0800 (PST)\r
+From: Jani Nikula <jani@nikula.org>\r
+To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org\r
+Subject: automatic database upgrades (was: Re: [PATCH 0/7] cli: notmuch new\r
+ improvements)\r
+In-Reply-To: <87ppnga21o.fsf@qmul.ac.uk>\r
+References: <cover.1390163335.git.jani@nikula.org> <87ppnga21o.fsf@qmul.ac.uk>\r
+User-Agent: Notmuch/0.17+44~ge3b4cd9 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sat, 25 Jan 2014 16:59:12 +0200\r
+Message-ID: <87lhy4f6pr.fsf@nikula.org>\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, 25 Jan 2014 14:59:27 -0000\r
+\r
+On Sat, 25 Jan 2014, Mark Walters <markwalters1009@gmail.com> wrote:\r
+> This series LGTM.\r
+\r
+Hi Mark, thanks for the review!\r
+\r
+> I do now recall there was some discussion on irc about the automatic\r
+> database upgrade: it would be good to have that documented but the\r
+> consensus was to do it, so +1 from me.\r
+\r
+Here's some summary, as promised. Please bear in mind that the\r
+discussion is pretty much irrelevant to this particular patch\r
+series. (We might discuss whether a warning about upgrade should be\r
+printed to stderr also with --quiet, but IMHO that can be a follow-up\r
+patch.)\r
+\r
+A database upgrade is required when the user upgrades to a new version\r
+of notmuch that has a modified database schema. See\r
+id:cover.1389304779.git.jani@nikula.org for an example of a proposed\r
+database change.\r
+\r
+A database upgrade is a rare event. Most of the time, it's okay to go\r
+back and forth with notmuch versions on the same database, but a\r
+database upgrade is an irreversible process after which the user must\r
+use the new version of notmuch. To go back requires a full rebuild of\r
+the database.\r
+\r
+We don't have recent experience with the database upgrades. The last\r
+time it happened was before notmuch 0.1 (yes, 0.1) was released, when\r
+the whole upgrade mechanism was introduced:\r
+\r
+commit 909f52bd8c4bdfa11cd3e75e3d0959e0293689bd\r
+Author: Carl Worth <cworth@cworth.org>\r
+Date: Thu Jan 7 18:26:31 2010 -0800\r
+\r
+ lib: Implement versioning in the database and provide upgrade function.\r
+\r
+Some of the points in favor of requiring manual intervention (such as\r
+running 'notmuch new --upgrade' or a new command 'notmuch upgrade')\r
+before upgrading the database:\r
+\r
+* The database upgrade is an irreversible process. The user should have\r
+ a chance to decide whether to go ahead with that. You can't go back to\r
+ the old notmuch and database version without rebuilding the database.\r
+\r
+* The user should be given the chance to make backups first in case\r
+ something goes wrong.\r
+\r
+* The database upgrade might take a long time for large databases. The\r
+ user should be able to choose when to go ahead with that.\r
+\r
+Some of the points in favor of upgrading automatically:\r
+\r
+* cworth: "One potential concern is that [requiring manual intervention]\r
+ effectively breaks notmuch until the user intervenese and runs this\r
+ new command. So that can complicate things for any interface that sits\r
+ on top of notmuch."\r
+\r
+* cworth: "In general, I'm often frustrated with programs that say "I\r
+ cannot continue until you run command <foo>.". If command <foo> needs\r
+ to be run, and the software knows it, why doesn't it just run it\r
+ itself? [...] So a message like "Run 'notmuch upgrade'" seems it could\r
+ corrode the user's trust in notmuch to maintain its own state."\r
+\r
+* There are people who run notmuch new non-interactively. There's no\r
+ easy answer to handling that if manual intervention is required.\r
+\r
+* It should always be okay to kill the upgrade, and continue at a later\r
+ time, in case it takes too long.\r
+\r
+Reading the logs again, I'm not so confident about us reaching a\r
+concensus. Maybe it was just me changing my mind during the course of\r
+the discussion... so we can try to reach concensus here.\r
+\r
+\r
+BR,\r
+Jani.\r
projects / notmuch-archives.git / commitdiff