[
https://issues.apache.org/jira/browse/LUCENE-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843910#comment-16843910
]
Adrien Grand commented on LUCENE-4012:
--------------------------------------
bq. 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
FYI it's not only about the query types that a parser supports. For instead the
classic query parsers creates synonym queries for terms that occur at the same
position, but it doesn't have a way to create a synonym query explicitly from 2
or more terms.
I agree that serialization of queries is important, but in my opinion it makes
things simpler to add serialization support to another, simpler, query layer
that would sit on top of Lucene and that only translates into Lucene queries
for the purpose of query execution. This layer doesn't have to care of the
details regarding how scores are merged across fields (dismax vs. bool vs.
BM25FQuery), whether any query terms included synonyms, how the field was
indexed (range query on points or terms don't translate to the same Lucene
query), whether some queries were introduced that only affect execution paths
but not matched results (IndexOrDocValueQuery), etc.
> 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]
