+1. Makes a lot of sense in general I think. Keeps them nicely thread safe as well, and as they are commonly used for keys in caches and such, that's a nice intrinsic property.
- Mark On Tue, Mar 31, 2015 at 7:24 AM Robert Muir <rcm...@gmail.com> wrote: > Same with BooleanQuery. the go-to ctor should just take 'clauses' > > On Tue, Mar 31, 2015 at 5:18 AM, Michael McCandless > <luc...@mikemccandless.com> wrote: > > +1 > > > > For PhraseQuery we could also have a common-case ctor that just takes > > the terms (and assumes sequential positions)? > > > > Mike McCandless > > > > http://blog.mikemccandless.com > > > > > > On Tue, Mar 31, 2015 at 5:10 AM, Adrien Grand <jpou...@gmail.com> wrote: > >> Recent changes that added automatic filter caching to IndexSearcher > >> uncovered some traps with our queries when it comes to using them as > >> cache keys. The problem comes from the fact that some of our main > >> queries are mutable, and modifying them while they are used as cache > >> keys makes the entry that they are caching invisible (because the hash > >> code changed too) yet still using memory. > >> > >> While I think most users would be unaffected as it is rather uncommon > >> to modify queries after having passed them to IndexSearcher, I would > >> like to remove this trap by making queries immutable: everything > >> should be set at construction time except the boost parameter that > >> could still be changed with the same clone()/setBoost() mechanism as > >> today. > >> > >> First I would like to make sure that it sounds good to everyone and > >> then to discuss what the API should look like. Most of our queries > >> happen to be immutable already (NumericRangeQuery, TermsQuery, > >> SpanNearQuery, etc.) but some aren't and the main exceptions are: > >> - BooleanQuery, > >> - DisjunctionMaxQuery, > >> - PhraseQuery, > >> - MultiPhraseQuery. > >> > >> We could take all parameters that are set as setters and move them to > >> constructor arguments. For the above queries, this would mean (using > >> varargs for ease of use): > >> > >> BooleanQuery(boolean disableCoord, int minShouldMatch, > >> BooleanClause... clauses) > >> DisjunctionMaxQuery(float tieBreakMul, Query... clauses) > >> > >> For PhraseQuery and MultiPhraseQuery, the closest to what we have > >> today would require adding new classes to wrap terms and positions > >> together, for instance: > >> > >> class TermAndPosition { > >> public final BytesRef term; > >> public final int position; > >> } > >> > >> so that eg. PhraseQuery would look like: > >> > >> PhraseQuery(int slop, String field, TermAndPosition... terms) > >> > >> MultiPhraseQuery would be the same with several terms at the same > position. > >> > >> Comments/ideas/concerns are highly welcome. > >> > >> -- > >> Adrien > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
