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
