Re: WIP: add metadata to dump output
authorTomi Ollila <tomi.ollila@iki.fi>
Sun, 10 Jan 2016 14:36:59 +0000 (16:36 +0200)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 23:20:50 +0000 (16:20 -0700)
17/deed1f264aaa7ed1dec178a32481d58724de2a [new file with mode: 0644]

diff --git a/17/deed1f264aaa7ed1dec178a32481d58724de2a b/17/deed1f264aaa7ed1dec178a32481d58724de2a
new file mode 100644 (file)
index 0000000..3fb276f
--- /dev/null
@@ -0,0 +1,123 @@
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 6DEA36DE140C\r
+ for <notmuch@notmuchmail.org>; Sun, 10 Jan 2016 06:36:52 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.665\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.665 tagged_above=-999 required=5 tests=[AWL=0.013, \r
+ SPF_NEUTRAL=0.652] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id X75JrYpvpNni for <notmuch@notmuchmail.org>;\r
+ Sun, 10 Jan 2016 06:36:50 -0800 (PST)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 8F4056DE0C66\r
+ for <notmuch@notmuchmail.org>; Sun, 10 Jan 2016 06:36:49 -0800 (PST)\r
+Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
+ by guru.guru-group.fi (Postfix) with ESMTP id 733C1100080;\r
+ Sun, 10 Jan 2016 16:36:59 +0200 (EET)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
+Subject: Re: WIP: add metadata to dump output\r
+In-Reply-To: <1452394301-29499-1-git-send-email-david@tethera.net>\r
+References: <1452394301-29499-1-git-send-email-david@tethera.net>\r
+User-Agent: Notmuch/0.21+32~g73439f8 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+ $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+ !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Sun, 10 Jan 2016 16:36:59 +0200\r
+Message-ID: <m2y4bxcxh0.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://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: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 10 Jan 2016 14:36:52 -0000\r
+\r
+On Sun, Jan 10 2016, David Bremner <david@tethera.net> wrote:\r
+\r
+> It seems (at least to me) that xapian metadata is the right way store\r
+> certain configuration data, including tag aliases [1] and perhaps some\r
+> non-CLI specific configuration. On the other hand we don't want to\r
+> have things lost if we dump and restore a database. Hence this series,\r
+> which is a start at dumping and restore such config.\r
+>\r
+> The main idea here is that various classes of metadata can be defined\r
+> by using prefixes, in exactly the same way as tags are defined for\r
+> documents. This will hopefully help prevent e.g. config from stomping\r
+> on tag aliases.\r
+>\r
+> The first 6 patches impliment iterators for simple "queries" on\r
+> metadata. They are probably split a bit fine, but that's the way I\r
+> developed them.\r
+>\r
+> The last 3 impliment the printing of metadata in dump output. In order\r
+> to be upwardly compatible, it uses the old dodge of hiding things in\r
+> comments. In fact the comment syntax (# in first column) was never\r
+> well documented; this does mean that the notmuch dump output can be\r
+> tested without breaking the current restore tests. I threw an @ in to\r
+> help autodetection of formats; obviously this is not foolproof. On the\r
+> other hand, I don't know how much people currently rely on comments in\r
+> dump files, since notmuch doesn't generate them.\r
+>\r
+> There's lots of bikes to shed here. Probably the most important bits\r
+> are the library API, the dump output format, and of course the ever\r
+> tricky command line argument names.\r
+\r
+Generally this series looks pretty good. IMO this could have gone with\r
+way less separate patches -- It would have made the review easier,\r
+now I had to go back to previous mails just to look context. But,\r
+anyone who disagrees w/ this make David know (in any appropriate \r
+channel so my opinion does not get too emphasized ;D)\r
+\r
+The first thing that came into my mind was this naming of\r
+*_FIRST_CLASS and *_LAST_CLASS in enum values. the naming\r
+is inconsistent in sense that first is first, but last is last + 1.\r
+Unfortunately there is nothing we can do with that as these *_LAST_*\r
+are used in other enums too so we just have to live with it. \r
+\r
+In last in this series there is\r
++typedef enum dump_includes {\r
++    DUMP_INCLUDE_TAGS=1,\r
++    DUMP_INCLUDE_METADATA=2,\r
++} dump_include_t;\r
+\r
+-- spacing around ' = ' missing -- I did not see other whitespace errors\r
+(not that there might not be those, though, as we know David ;)\r
+\r
+One bug I found:\r
+\r
++    for (mclass = NOTMUCH_METADATA_FIRST_CLASS; mclass < NOTMUCH_METADATA_LAST_CLASS; mclass++) {\r
++      status = notmuch_database_get_all_metadata (notmuch, NOTMUCH_METADATA_CONFIG, &meta);\r
+\r
+(mclass should be there). Currently as there is only that one in the enum\r
+there is no problem -- also for the same reason current test can not \r
+notice this. If this were not fixed, this would be noticed in the future\r
+by that particular test - unless it is changed erronelously ;)\r
+\r
+\r
+Anyway, good stuff in general...\r
+\r
+\r
+Tomi\r
+\r
+> Getting the memory ownership semantics is tricky, especially with the\r
+> mix of C++ objects and talloc. So I'd appreciate a critical eye on\r
+> those bits of metadata.cc.\r
+\r
+uh puh -- maybe I look that again (hmm, have to apply the patch series as\r
+all of the metadata.cc is not in one patch ;/\r