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

Andrew Sutherland asutherland at
Tue Mar 21 17:27:54 UTC 2017

On Tue, Mar 21, 2017, at 11:02 AM, opto at wrote:
> output after tag removed (per UI, not by code):
> /20160819203619.64E2E5C0A at;aaa1 at;

Which UI are you referring to?  Note that an intentional UI decision was
made for gloda-backed thread-pane views.  Messages will never be removed
from the thread pane even if they no longer apply to the underlying
query for purposes of UI stability and consistency with other similar
thread-pane use-cases.  See
where we ignore the removal notification.
> Now, we have an empty label string returned for a headermessageID that
> has no longer a tag in the UI. Strictly speaking, this message should not
> have been returned by gloda, because there is no tag.
> So it seems upon removing all tags, the indexer enters 57:<empty string>
> into the json. Instead, it should remove the 57:  entry alltogether (or
> was it 58 for tags?).

"tag" is 57 in my db, and in my non-scientific sampling of my database,
I see it encoded as `"57":[]` which is correctly an empty list.  (Noting
that it will stringify to an empty list, specifically: `[].toString()
=== ''`).

If you're saying that a fresh tags query is returning the correctly
no-tags message, then I think what is happening is the database is
out-of-date but the in-memory representation is correct.  Specifically,
the pseudo-code for message queries looks like:
- Ask the database for the message id's matching the query.
- Check if we have representations of those messages in memory by
walking through the list of all known message queries/collections. 
(This is done magically using weak references rather than reference
counting.  So if you are holding any collections alive in memory, their
gloda items will continue to be updated as the indexer mutates them. 
Noting that there's ever only a single instance of a given gloda item.) 
If we have one in memory, return that reference.
- Retrieve the messages from the database that we didn't already have in

If the database change is not happening or is being rolled back, it's
absolutely a bug in gloda or related code.

You might want to try running Thunderbird with the following environment
variable set: "MOZ_LOG=mozStorage:5".  This will result in all database
mutations being logged to stdout as they occur.  You can ensure that
when you change the tags that the database writes are occurring.  You'll
also want to keep an eye on the "COMMIT" message eventually being
applied and that no errors triggering rollbacks occur.  (Gloda uses
long-running transactions for performance and historical reasons.  See
the code documentation for more info.)


More information about the tb-planning mailing list