[ https://issues.apache.org/jira/browse/LUCENE-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259305#comment-13259305 ]
Robert Muir commented on LUCENE-4012: ------------------------------------- My first question is, what about backward compatibility requirements? The problem is if people start using such a structure ('remote api') that depends upon the structure of our java source code, then they will be upset if we break it. If we totally change a Query's API, does that push all the responsibility of the API designer to deal with serialization backwards compat? APIs are difficult enough as-is just for java consumers. This seems similar to the java serialization issue (which we removed for this reason). Can't the serialization be totally independent? > 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