lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4012) Make all query classes serializable with Jackson, and provide a trivial query parser to consume them
Date Tue, 01 May 2012 17:20:49 GMT


Robert Muir commented on LUCENE-4012:

I think if it works for you, just iterate in your github and ping the issue when you make
Otherwise we worry too much about where/how the code sits when that isn't really so important
at this stage.

As far as final integration, I think there are a number of ways to do it but its really
unrelated to making progress here. One suggestion might be to split queryparser/ module
like analyzers/ so we have:
* classic/ [including things based on it: complexPhrase, ext, analyzing]
* flexible/ [including precedence which is based on it]
* xml/
* json/

This could probably make things less confusing, as currently queryparser/ is a mix of
different frameworks with different dependencies (e.g. xml depends on queries/ and sandbox/,
but the others dont, and json will depend on jackson and maybe other stuff, etc, etc).

And then finally, probably a followup issue to do solr integration (i'm more fuzzy on that).

> Make all query classes serializable with Jackson, and provide a trivial query parser
to consume them
> ----------------------------------------------------------------------------------------------------
>                 Key: LUCENE-4012
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: core/queryparser
>    Affects Versions: 4.0
>            Reporter: Benson Margulies
>         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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message