This should be handled in WildcardTermEnum instead of overriding MultiTermQuery#rewrite(). The WildcardTermEnum could simply return false in termCompare if a term is not equal to the "prefix". This would yield consistent behaviour even if a custom RewriteMethod is used. Right?!
simon On Wed, Oct 7, 2009 at 11:17 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > +1 > > I think it ought to be faster? PrefixTermEnum just calls .startsWith > on each term text, but WildcardTermEnum has big hairy logic in > wildcardEquals. > > Mike > > On Tue, Oct 6, 2009 at 11:43 PM, Robert Muir <rcm...@gmail.com> wrote: >> separately, perhaps we should consider doing the prefixquery rewrite >> here for wildcardquery. >> >> for example, SolrQueryParser will emit these 'wildcardqueries that >> should be prefixqueries' if you are using the new reverse stuff for >> leading wildcards: WildcardQuery(*foobar) -> >> WildcardQuery(U+0001raboof*) >> >> I don't think the prefix enumeration is really that much faster than >> the wildcard one, but still thought I would mention it. >> >> On Tue, Oct 6, 2009 at 10:22 PM, Robert Muir <rcm...@gmail.com> wrote: >>> someone asked this question on the user list: >>> http://www.lucidimagination.com/search/document/6f38de391b242102/prefixquery_vs_wildcardquery >>> >>> it made me look at the wildcard rewrite(), where i see this: >>> if (!termContainsWildcard) >>> return new TermQuery(getTerm()); >>> >>> is it a problem the boost is not preserved in this special case? >>> >>> is it also a problem that if the user sets the default MultiTermQuery >>> rewriteMethod to say, CONSTANT_SCORE_FILTER_REWRITE, >>> that this rewritten TermQuery isn't wrapped with a constant score? >>> >>> Sorry if it seems a bit nitpicky, really the issue is that I want to >>> do the right thing for a more complex query I am working on, but don't >>> want to overkill either. >>> -- >>> Robert Muir >>> rcm...@gmail.com >>> >> >> >> >> -- >> Robert Muir >> rcm...@gmail.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
