Re: [PATCH 9/9] add has: query prefix to search for specific properties
[notmuch-archives.git] / 17 / deed1f264aaa7ed1dec178a32481d58724de2a
1 Return-Path: <tomi.ollila@iki.fi>\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 arlo.cworth.org (Postfix) with ESMTP id 6DEA36DE140C\r
6  for <notmuch@notmuchmail.org>; Sun, 10 Jan 2016 06:36:52 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 0.665\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=0.665 tagged_above=-999 required=5 tests=[AWL=0.013, \r
12  SPF_NEUTRAL=0.652] autolearn=disabled\r
13 Received: from arlo.cworth.org ([127.0.0.1])\r
14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
15  with ESMTP id X75JrYpvpNni for <notmuch@notmuchmail.org>;\r
16  Sun, 10 Jan 2016 06:36:50 -0800 (PST)\r
17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
18  by arlo.cworth.org (Postfix) with ESMTP id 8F4056DE0C66\r
19  for <notmuch@notmuchmail.org>; Sun, 10 Jan 2016 06:36:49 -0800 (PST)\r
20 Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
21  by guru.guru-group.fi (Postfix) with ESMTP id 733C1100080;\r
22  Sun, 10 Jan 2016 16:36:59 +0200 (EET)\r
23 From: Tomi Ollila <tomi.ollila@iki.fi>\r
24 To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
25 Subject: Re: WIP: add metadata to dump output\r
26 In-Reply-To: <1452394301-29499-1-git-send-email-david@tethera.net>\r
27 References: <1452394301-29499-1-git-send-email-david@tethera.net>\r
28 User-Agent: Notmuch/0.21+32~g73439f8 (http://notmuchmail.org) Emacs/24.3.1\r
29  (x86_64-unknown-linux-gnu)\r
30 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
31  $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
32  !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
33 Date: Sun, 10 Jan 2016 16:36:59 +0200\r
34 Message-ID: <m2y4bxcxh0.fsf@guru.guru-group.fi>\r
35 MIME-Version: 1.0\r
36 Content-Type: text/plain\r
37 X-BeenThere: notmuch@notmuchmail.org\r
38 X-Mailman-Version: 2.1.20\r
39 Precedence: list\r
40 List-Id: "Use and development of the notmuch mail system."\r
41  <notmuch.notmuchmail.org>\r
42 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
43  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
44 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
45 List-Post: <mailto:notmuch@notmuchmail.org>\r
46 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
47 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
48  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
49 X-List-Received-Date: Sun, 10 Jan 2016 14:36:52 -0000\r
50 \r
51 On Sun, Jan 10 2016, David Bremner <david@tethera.net> wrote:\r
52 \r
53 > It seems (at least to me) that xapian metadata is the right way store\r
54 > certain configuration data, including tag aliases [1] and perhaps some\r
55 > non-CLI specific configuration. On the other hand we don't want to\r
56 > have things lost if we dump and restore a database. Hence this series,\r
57 > which is a start at dumping and restore such config.\r
58 >\r
59 > The main idea here is that various classes of metadata can be defined\r
60 > by using prefixes, in exactly the same way as tags are defined for\r
61 > documents. This will hopefully help prevent e.g. config from stomping\r
62 > on tag aliases.\r
63 >\r
64 > The first 6 patches impliment iterators for simple "queries" on\r
65 > metadata. They are probably split a bit fine, but that's the way I\r
66 > developed them.\r
67 >\r
68 > The last 3 impliment the printing of metadata in dump output. In order\r
69 > to be upwardly compatible, it uses the old dodge of hiding things in\r
70 > comments. In fact the comment syntax (# in first column) was never\r
71 > well documented; this does mean that the notmuch dump output can be\r
72 > tested without breaking the current restore tests. I threw an @ in to\r
73 > help autodetection of formats; obviously this is not foolproof. On the\r
74 > other hand, I don't know how much people currently rely on comments in\r
75 > dump files, since notmuch doesn't generate them.\r
76 >\r
77 > There's lots of bikes to shed here. Probably the most important bits\r
78 > are the library API, the dump output format, and of course the ever\r
79 > tricky command line argument names.\r
80 \r
81 Generally this series looks pretty good. IMO this could have gone with\r
82 way less separate patches -- It would have made the review easier,\r
83 now I had to go back to previous mails just to look context. But,\r
84 anyone who disagrees w/ this make David know (in any appropriate \r
85 channel so my opinion does not get too emphasized ;D)\r
86 \r
87 The first thing that came into my mind was this naming of\r
88 *_FIRST_CLASS and *_LAST_CLASS in enum values. the naming\r
89 is inconsistent in sense that first is first, but last is last + 1.\r
90 Unfortunately there is nothing we can do with that as these *_LAST_*\r
91 are used in other enums too so we just have to live with it. \r
92 \r
93 In last in this series there is\r
94 +typedef enum dump_includes {\r
95 +    DUMP_INCLUDE_TAGS=1,\r
96 +    DUMP_INCLUDE_METADATA=2,\r
97 +} dump_include_t;\r
98 \r
99 -- spacing around ' = ' missing -- I did not see other whitespace errors\r
100 (not that there might not be those, though, as we know David ;)\r
101 \r
102 One bug I found:\r
103 \r
104 +    for (mclass = NOTMUCH_METADATA_FIRST_CLASS; mclass < NOTMUCH_METADATA_LAST_CLASS; mclass++) {\r
105 +       status = notmuch_database_get_all_metadata (notmuch, NOTMUCH_METADATA_CONFIG, &meta);\r
106 \r
107 (mclass should be there). Currently as there is only that one in the enum\r
108 there is no problem -- also for the same reason current test can not \r
109 notice this. If this were not fixed, this would be noticed in the future\r
110 by that particular test - unless it is changed erronelously ;)\r
111 \r
112 \r
113 Anyway, good stuff in general...\r
114 \r
115 \r
116 Tomi\r
117 \r
118 > Getting the memory ownership semantics is tricky, especially with the\r
119 > mix of C++ objects and talloc. So I'd appreciate a critical eye on\r
120 > those bits of metadata.cc.\r
121 \r
122 uh puh -- maybe I look that again (hmm, have to apply the patch series as\r
123 all of the metadata.cc is not in one patch ;/\r