[jira] [Commented] (LUCENE-4012) Make all query classes serializable, and provide a query parser to consume them

["Mike Sokolov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843445#comment-16843445 ] 

Mike Sokolov commented on LUCENE-4012:
--------------------------------------

I want to hijack this issue to be about maing Query serializable by any means necessary.  The idea of using Jackson seemed like it could be problematic since it tends to expose implementation details (constructor signatures, eg), but the idea of query serialization is powerful, and we should have it in our bag of tricks. A whole class of optimizations stems from analysis of query logs, and in order to treat queries as data we need a persistent form for them (not just in-memory java Query objects).

It seems like we have a good angle of attack since LUCENE-3041 landed, adding a QueryVisitor. My thought is that each query parser could potentially come with a serializer that serializes queries into its language, since not every parser can represent every query type. Or maybe XML query parser is truly general and handles everything thus there is no need for any other flavor? I'm not sure though I seem to recall it has some gaps as well.

I worked up a POC that serializes combinations of Boolean and TermQuery into a form that is parseable by classic query parser, and I think it can be extended pretty easily to cover most query types. I have a question here: to get it to work it seemed as if I needed to make BooleanQuery.visit call getSubVisitor for every clause (rather than once for each occur-value). This broke a single test though in TestQueryVisitor that asserts something about the sequence of these calls, and I'm not sure if that assertion is an invariant of the QueryVisitor contract, or whether it is simply a byproduct of the implementation. [~romseygeek] can you shed some light?  I can post a WIP PR if that would help clarify.

> Make all query classes serializable, and provide a query parser to consume them
> -------------------------------------------------------------------------------
>
>                 Key: LUCENE-4012
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4012
>             Project: Lucene - Core
>          Issue Type: New Feature
>          Components: core/queryparser
>    Affects Versions: 4.0-ALPHA
>            Reporter: Benson Margulies
>            Priority: Major
>         Attachments: bq.patch
>
>
> I started off on LUCENE-4004 wanting to use DisjunctionMaxQuery via a parser. However, this wasn't really because I thought that human beans should be improvisationally  composing such thing. My real goal was to concoct a query tree over *here*, and then serialize it to send to Solr over *there*. 
> It occurs to me that if the Xml parser is pretty good for this, JSON would be better. It further occurs to me that the query classes may already all work with Jackson, and, if they don't, the required tweaks will be quite small. By allowing Jackson to write out class names as needed, you get the ability to serialize *any* query, so long as the other side has the classes in class path. A trifle verbose, but not as verbose as XML, and furthermore squishable (though not in a URL) via SMILE or BSON.
> So, the goal of this JIRA is to accumulate tweaks to the query classes to make them more 'bean pattern'. An alternative would be Jackson annotations. However, I suspect that folks would be happier to minimize the level of coupling here; in the extreme, the trivial parser could live in contrib if no one wants a dependency, even optional, on Jackson itself.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org