removing query attributes from gloda - which are allowed now? (refer to Jonathan's anouncement of 2011)

Andrew Sutherland asutherland at asutherland.org
Mon Mar 20 16:58:13 UTC 2017


> 1) in the sqlite, I have two gloda-id's of 2. Would that be expected (in
> messags table).

That's a sentinel value for a message that fails to index.  See the
comments at
https://dxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/index_msg.js#55

That does seem like a bug since the point of that gloda id is that it's
supposed to be annotated onto the nsIMsgDBHdr.  I don't think it's ever
supposed to be stored in the database.  I can't tell if that's a
harmless bug in optimized event-driven indexing issuing blind mutations
or the cause of all your trouble.

It might be a useful debugging exercise to delete the messages gloda is
labeling with a 2, or at least put them in a folder you explicitly tell
gloda not to index.  You'd want to reindex after doing that.

> 2) I observe that tags don't make it into gloda? Using glodaquiölla, I
> see that after setting a new tag, the message is indexed (meaning: dirty
> is removed from header, see glodauilla). Using the query for tags as
> described above, the number of results returned by the query does not
> change. I see 4 tagged messages in the 3 pane window, but gloda returns a
> count of 2.
> The other day, I had a count of 3 (but only 2 messages with tags). After
> deleting the sqlite db, the count went down to 2. So removing tags did
> not seem to update gloda.
> for the message list with 4 messages tagged, I again deleted the sqlite
> db. Now, after TB restart,  glodaquilla reports that no message is dirty,
> but the count of tags is 0.

Gloda queries should update in real-time as the database is modified. 
This makes it sound like the indexing process is failing in weird ways. 
Definitely try and collect and examine some logs.

> Background info: as our IMAP server does not store keywords, I want to
> make an addon that can backup/restore tags for messages. To dublicate the
> tags on a second TB installation, also as precaution when TB looses tags
> (happened recently after an update - the message summaries for inbox were
> gone, and after repair, all tags were gone as well.

That sounds like a very unfortunate IMAP server situation.  I'd suggest
switching to a better IMAP implementation by whatever means necessary.

Andrew


More information about the tb-planning mailing list