[
https://issues.apache.org/jira/browse/LUCENE-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259310#comment-13259310
]
Benson Margulies commented on LUCENE-4012:
------------------------------------------
Now you've got me thinking. Several points:
First, Jackson is far, far, less implementation-sensitive than the built-in
Java serialization. It looks at the public API of constructors, getters, and
setters. How likely are you to change the API in a way that invalidates the
idea that a TermQuery consists of a term name and a value?
Second, this is not about long-term persistence. I'd be happy to document it as
'do not expect to move one of these across versions.' It's most obvious
application is to move arbitrary queries around in SolrCloud.
However, thirdly, you want it independent? I can make it independent. Here's
how. Let's assume that you are willing to state the same sort of invariants for
a query object that are embodied in parser support. Once you make a parser for
something, you've promised that it has (at least) a particular set of inputs
until the next major version, yes?
So, for each Query object class, make a Jackson mixin class, that maps the
'official inputs' to the current collection of setters/constructor arguments.
Want to re-wrangle the query classes? If you actually change the
constructors/setters that you would use in a query parser for a particular
query, you then have to change the mixin class.
If it were up to me, I'd start by annotating the actually classes themselves
with Jackson @nnotations for this purpose, and only create mixins when and if
an incompatible change happened, but I'm not really opinionated.
Would it be sensible to start to concoct a contrib module with all the jackson
in it, accompanied by benign 'add a few getters and setters' classes to the
queries?
> Make all query classes serializable with Jackson, and provide a trivial query
> parser to consume them
> ----------------------------------------------------------------------------------------------------
>
> Key: LUCENE-4012
> URL: https://issues.apache.org/jira/browse/LUCENE-4012
> Project: Lucene - Java
> Issue Type: New Feature
> Components: core/queryparser
> Affects Versions: 4.0
> Reporter: Benson Margulies
>
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
