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

Benson Margulies commented on LUCENE-4012:
------------------------------------------

Rob,

These are not Java annotations, they are specific to Jackson. (Though Jackson 
will pay attention to the JAX-B annotations in Java 6, I fear that this is a 
cure worse than the disease.) So hanging them on the real classes makes for a 
hard dependency on Jackson to compile, and I'm not sure myself that this is a 
good idea in the middle of Lucene. If I stick to the mixin approach, no 
annotation are needed at all.

As for the rest, I think that we agree. The point of the annotations is to only 
serialize the stuff that makes up the plausible, stable, sort of attributes 
that you would support in a parser syntax. (though I suppose someone might want 
to SolrCloudify some really expert complexity), and the selective annotation 
avoids the rest.

So I'm going to sketch something out and we'll all see what it looks like.

                
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to