Adrien, Thanks for the explanation. It seems a pity to make queries just nearly immutable. Do you have any interest in adding a boost parameter to clone() so they really could be immutable?
--Terry On Tue, Mar 31, 2015 at 9:44 AM, Adrien Grand <jpou...@gmail.com> wrote: > Hi Terry, > > Indeed this is for query rewriting. For instance if you have a boolean > query with a boost of 5 that wraps a single MUST clause with a term > query, then we rewrite to this to the inner term query and update its > boost using clone() and setBoost() in order to not modify in-place a > user-modified query. > > On Tue, Mar 31, 2015 at 3:37 PM, Terry Smith <sheb...@gmail.com> wrote: > > Adrien, > > > > I missed the reason that boost is going to stay mutable. Is this to > support > > query rewriting? > > > > --Terry > > > > > > On Tue, Mar 31, 2015 at 7:21 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 > >> > > > > > > -- > Adrien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
