gloda: GlodaQuery needs to be serializable/deserializable, so that saved searches can be made from gloda-based searches



10 years ago
3 years ago


(Reporter: davida, Unassigned)


Firefox Tracking Flags

(Not tracked)




10 years ago
In order to implement "starred searches" (saved gloda-based searches), GlodaQuery objects need to know how to serialize themselves, and a factory method that takes a serialized form and returns a GlodaQuery need to be implemented.


8 years ago
Blocks: 468808


8 years ago
Assignee: nobody → schmid-thomas


8 years ago

Comment 1

8 years ago
I looked through the Gloda code, but in order to fix this I need some support. Until now I have only a rough idea how gloda works. It is really flexible but also confusing. Especially as the documentation is not very good, it's difficult for me to distinguish what could be a good starting point. Any suggestions are highly welcome.
Hmm, yeah, this might not be the best "intro to gloda" bug.

Since I believe your desired use-case is just to provide persistence of our gloda-based tabs, it might be easier (although hackier) to deal with this at a higher level, which means just re-creating queries manually during the tab logic.  The specific constraint types we support are:
- faceted search: fulltext search, search by contact/identity, search by tag
- show in conversation: conversation id, gloda explicit query "show as list"

In any event, here are the major things the patch would need to do, although you may not want to be the one to do them, at least not yet.  

1) Serialize the implementations in query.js to a JSON-able representation.  This could be accomplished by implementing toJSON methods as supported by JSON.stringify.  Special query classes (GlodaNullQueryClass, GlodaExplicitQueryClass, GlodaWildcardQueryClass) should definitely indicate their type.

2) Have a factory method that can reconstruct queries from the above output; adding a queryFromJSON method to Gloda in gloda.js might be the best way to expose it.  It would need to consult the query type to figure out which sub-class should be instantiated.  The query classes could implement a fromJSON method that would take the representation and reset their internal state to comply with the passed-in value.

3) Normalize representations of constraints into something persistable.  Specifically, a lot of rich object representations are actually characterized by their numeric "id" field, but right now we may hold the in-memory representation in the query.  For example, you could do "query.conversation(someConversationObject)" or "query.conversation(" and we store whatever you give us.  The representation gets fully normalized through use of the noun definition's toParamAndValue in query.js in the "test" function and in datastore.js in the _convert* methods; arguably this is a design flaw but there are some reasons it is beneficial; see point 4.

The simplest way to deal with this is to use the toParamAndValue function supported by nouns immediately when the user invokes the "query.conversation" method.  This can be accomplished by altering the _bindAttribute method to do this.  The places where we currently call toParamAndValue in query.js and datastore.js would no longer need to invoke it.  I believe the defineNoun invocation for "folder" in gloda.js may also need to assume an integer value passed in references a folder.

4) Strongly consider implementing a mechanism to respond to changes in the objects that are part of the query, filing a [gloda key] bug if not dealt with.  Specifically, although identify things by their "id" simplifies things, this only works perfectly if id's can never be merged/changed.  Although this is largely the case, ideally gloda would be able to merge conversations/contacts, which would change things.  (There is also the class of cases where things can be obliterated, like all messages in a conversation being deleted.  At that point, the query arguably is nonsensical and should be destroyed, but that's pretty fancy.)

The benefit of us not storing things as id's is that the system can transparently fix-up objects as long as they are known to the caching layer.  (Noting that query constraints are currently not rooted and so there is no guarantee the caching layer knows about them unless care is taken by the caller to hold onto the collection that provided the objects.)

This raises the alternate strategy of not normalizing everything to id's immediately, but instead having the query restoration process be asynchronous so that we can load the required objects from disk in order to leverage the object magic.
There doesn't seem to be any movement on this, so (unless Thomas objects), I'm going to mark this as unassigned.

I might take this one soon, since we want to be able to move search queries from window to window.
Assignee: schmid-thomas → nobody


3 years ago
Summary: gloda: GlodaQuery needs to be serializable/deserializable → gloda: GlodaQuery needs to be serializable/deserializable, so that saved searches can be made from gloda-based searches
You need to log in before you can comment on or make changes to this bug.