On Wed, Nov 10, 2010 at 8:05 AM, Erick Erickson <erickerick...@gmail.com> wrote: > Has anyone opened a JIRA on this? >
I'm not sure if we should call it a bug or not (in this particular example, it would be nice if we could find a fix i think though). Because in general we can't guarantee MultiSearcher(Searcher...) will return the same results as MultiReader for MultiTermQueries like RangeQuery... it depends on the rewrite method. For the Filter rewrite, i think they will be mostly or always the same. But when rewriting to booleanqueries, its going to be inconsistent by definition, since the rewrite happens for each sub and then is combined... but this isn't necessary equivalent to performing the rewrite on a single MultiReader, especially when the rewrite method has some notion of "top-N" even if N=max boolean clause count. the inconsistencies i'm sure will revolve around things like exceeding max clause count (probably even with CONSTANT_SCORE_AUTO!!!), combine()ing queries that are really top-N rewrites (e.g. fuzzy or using toptermsrewrite anywhere else), and maybe corner cases like your example where the multitermquery rewrites to a simpler form for an individual sub. Maybe we should just deprecate and remove MultiSearcher? Why not just use a MultiReader instead? --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
