[
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: [email protected]
For additional commands, e-mail: [email protected]
