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