removing query attributes from gloda - which are allowed now? (refer to Jonathan's anouncement of 2011)
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
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.
More information about the tb-planning