<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<b>tl;dr</b><br>
<br>
If you're using any sort of gloda query in your Thunderbird addon,
please reply immediately to this thread and tell us which message
attributes (from, starred, tags, ...) you're searching on. See <a
class="moz-txt-link-rfc2396E"
href="https://developer.mozilla.org/en/Thunderbird/Creating_a_Gloda_message_query"><https://developer.mozilla.org/en/Thunderbird/Creating_a_Gloda_message_query></a>
for a refresher. Track progress at
<a class="moz-txt-link-rfc2396E" href="https://bugzilla.mozilla.org/show_bug.cgi?id=678405"><https://bugzilla.mozilla.org/show_bug.cgi?id=678405></a>.<br>
<br>
<b>the story</b><br>
<br>
I'm currently working on boosting the performance of the Gloda
database. Gloda was initially designed with high hopes in mind, and
as such, has an extremely powerful query mechanism: one can say
"return all read messages", or "return all messages with John in
CC", etc. This is explained at <a class="moz-txt-link-rfc2396E"
href="https://developer.mozilla.org/en/Thunderbird/Creating_a_Gloda_message_query"><https://developer.mozilla.org/en/Thunderbird/Creating_a_Gloda_message_query></a>.
However, this power comes with a cost: there's a <tt>messageAttributes</tt>
table that (roughly) contains a list of triples message id /
attribute id / attribute value, so that you can query on these
attributes. This means there are many, many rows in that table.<br>
<br>
<blockquote> jonathan@ramona:~ $ sqlite3
~/.thunderbird/4ckb7o7v.default/global-messages-db.sqlite <br>
SQLite version 3.7.6.3<br>
Enter ".help" for instructions<br>
Enter SQL statements terminated with a ";"<br>
sqlite> select count(*) from messageAttributes;<br>
<b>930757</b><br>
</blockquote>
<br>
I have nearly one million rows in that table. This not only costs
space but also computing power, since sqlite needs to maintain an
index on that table.<br>
<br>
<b>the plan</b><br>
<br>
I plan on making this opt-in: that is, when an attribute is defined,
by default, it won't generate rows in <tt>messageAttributes</tt>.
This should be a big win, if not the biggest of this summer's gloda
improvements. The attributes will still be <i>readable</i> once you
have the <tt>GlodaMessage</tt> handy: they're also stored in the
JSON blob that belongs to the <tt>messages</tt> table; simply, you
won't be able to <i>query</i> on them. Making this opt-in will help
make sure people who define their own attributes don't add an extra
burden to the table. Most Gloda internal attributes will remain
searchable, however, we plan to make a fair number non-searchable
(non exhaustive list):<br>
<pre class="bz_comment_text" id="comment_text_0">read, fromMe, toMe, to, cc, bcc, isEncrypted, attachmentInfos, repliedTo, forwarded.</pre>
<br>
<b>the call</b><br>
<br>
If you or your extension depends on being able query on these
attributes, <u><b>speak up now</b></u> and we can make sure you
still have the ability to query on these attributes. Otherwise, this
ability will go away soon (Thunderbird 9). As far as I know, I'm the
only one (Thunderbird Conversations) making serious use of Gloda.
:TheOne from IRC mentioned using headerMessageID. If you're using
Gloda in your Thunderbird addon, we'd like to know about it. Really.<br>
<br>
Please note that if you use the attributes to refine a query, you
can still filter them manually afterwards: instead of doing a query
on <i>message from Bob</i> AND <i>message read</i>, you can just
do a query on <i>message from Bob</i>, and then filter the results
to only keep read messages.<br>
<br>
If anything is unclear, I'd be happy to clarify.<br>
<br>
Cheers,<br>
<br>
jonathan<br>
</body>
</html>