[
https://issues.apache.org/jira/browse/LUCENE-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259318#comment-13259318
]
Robert Muir commented on LUCENE-4012:
-------------------------------------
{quote}
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?
{quote}
TermQuery currently has a bogus constructor today:
{code}
/** Expert: constructs a TermQuery that will use the
* provided docFreq instead of looking up the docFreq
* against the searcher. */
public TermQuery(Term t, int docFreq) {
{code}
Its bogus because some scoring models may not use docFreq at all (e.g. language
modelling): I know why it exists (for one contrib query), I think we have a
plan to fix it, but its just not yet done... like many things :)
But thats an example of one I think is fair to remove in a minor release:
besides being bogus, its documented as Expert,
so its fair game.
I'm just bringing this up as a counterexample... I thought serialization was
harmless before myself
until I tried to make useful changes (like yanking vector-space model out of
the scoring system) and was
totally blocked by serialization. So I'm gonna be suspicious of the word no
matter what :)
{quote}
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.
{quote}
Are these annotations in java 6 API? Annotations are no different than other
pieces of code, they are an additional
responsibility. As far as @Deprecated, we fail the build if we add @deprecated
javadocs but forget it, as far as
@Override, well nothing automated yet, but we should be somehow enforcing that
as well. Besides the fact we don't
want to add any dependencies to the lucene core, how would we know such
annotations were correct?
{quote}
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?
{quote}
Don't let me get in your way: I'm just the devil's advocate when i hear
serialization. As far as adding getters and setters
to queries I'm not sure if they are benign or not without us looking at them.
For example, AutomatonQuery and all of its
subclasses: Wildcard, Regexp, etc are totally immutable once created. This is
for good reasons so I don't think we should
add any setters to these classes, and the stuff it stores internally shouldn't
be accessible via a getter.
> 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]
