[
https://issues.apache.org/jira/browse/LUCENE-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1951.
Resolution: Fixed
Fix Version/s: 3.0
Thanks Robert!
> wildcardqu
rive at the TermQuery, but I think the
test is fine?
Ok, that was my only concern, the test. I like the SingleTermEnum otherwise, I
think it will reduce maintenance.
> wildcardquery rewrite improvements
> --
>
> Key: LUCENE-1951
>
way to arrive at the TermQuery, but I think the
test is fine?
> wildcardquery rewrite improvements
> --
>
> Key: LUCENE-1951
> URL: https://issues.apache.org/jira/browse/LUCENE-1951
> Project: Lucene -
Enum -> MultiTermQuery -> BooleanQuery with one term -> TermQuery.
I couldnt think of a better way to test the correct behavior, but it is testing
a bit more than just what happens in WildcardQuery...
> wildcardquery rewrite improvements
> --
>
>
anks. I'll commit soon.
> wildcardquery rewrite improvements
> --
>
> Key: LUCENE-1951
> URL: https://issues.apache.org/jira/browse/LUCENE-1951
> Project: Lucene - Java
> Issue Type: Imp
when there are
no wildcards to preserve all the MultiTermQuery semantics.
> wildcardquery rewrite improvements
> --
>
> Key: LUCENE-1951
> URL: https://issues.apache.org/jira/browse/LUCENE-1951
> Proj
d be objection to making this proposed SingleTermEnum
public?
I think that's fine.
> wildcardquery rewrite improvements
> --
>
> Key: LUCENE-1951
> URL: https://issues.apache.org/jira/browse/LUCENE-1951
>
this proposed SingleTermEnum public?
I would like to use it in LUCENE-1606 (contrib) to have consistency there as
well.
> wildcardquery rewrite improvements
> --
>
> Key: LUCENE-1951
> URL: https://issues.apache.org
but didnt know what to do.
I rather like the SingleTermEnum idea. I'll do it.
> wildcardquery rewrite improvements
> --
>
> Key: LUCENE-1951
> URL: https://issues.apache.org/jira/browse/LUCENE-1951
>
be to make a degenerate
"SingleTermEnum" (subclasses FilteredTermEnum) that produces only a
single term? Then in getEnum we could return that, instead, so the
rewrite method remains intact?
> wildcardquery rewrite improvements
> --
>
>
[
https://issues.apache.org/jira/browse/LUCENE-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1951:
--
Assignee: Michael McCandless
> wildcardquery rewrite improveme
wildcard rewrite test.
> wildcardquery rewrite improvements
> --
>
> Key: LUCENE-1951
> URL: https://issues.apache.org/jira/browse/LUCENE-1951
> Project: Lucene - Java
> Issue Type: Improvement
ly be TermQuery when rewriteMethod is
SCORING_BOOLEAN_QUERY_REWRITE. and this is not the default, constant score is.
easiest way to fix the old test is to
setRewriteMethod(SCORING_BOOLEAN_QUERY_REWRITE), its the only time it should
rewrite to TermQuery.
> wildcardque
is longer: in this case wildcard's comparison function might
have to do even more work.
I'll work on a patch to fix the boost/constant score and include a prefixquery
rewrite for this case.
> wildcardquery rewrite improvements
> --
>
>
Mark, I am set up to do these tests with a large term dict. I will see
if there is any improvement.
In my opinion in general, even if the improvement is very small, if
its trivial to rewrite to a faster/simpler query, we should.
Future improvements to lucene might make the simpler query might
beco
bq. I don't think the prefix enumeration is really that much faster than
the wildcard one,
We should do some tests. If it is much faster, this would be a nice
optimization. I think it could be worth it when matching a
lot of terms - never tested though.
Robert Muir wrote:
> separately, perhaps we
sure, I will submit a patch under LUCENE-1951.
will look around at other rewrites too just to be sure there arent others
Thanks,
Robert
On Wed, Oct 7, 2009 at 5:15 AM, Michael McCandless
wrote:
> I agree, this looks like a bug (boost & constant-score-ness is lost)
> -- wanna open an issue & pat
wildcardquery rewrite improvements
--
Key: LUCENE-1951
URL: https://issues.apache.org/jira/browse/LUCENE-1951
Project: Lucene - Java
Issue Type: Improvement
Components: Query/Scoring
i think it does this already. so like i said, it would be a minor optimization.
On Wed, Oct 7, 2009 at 6:16 AM, Simon Willnauer
wrote:
> This should be handled in WildcardTermEnum instead of overriding
> MultiTermQuery#rewrite(). The WildcardTermEnum could simply return
> false in termCompare if
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
+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 wrote:
> separately, perhaps we should consider doing the prefixquery rewrite
> here for wild
I agree, this looks like a bug (boost & constant-score-ness is lost)
-- wanna open an issue & patch it?
Mike
On Tue, Oct 6, 2009 at 10:22 PM, Robert Muir wrote:
> someone asked this question on the user list:
> http://www.lucidimagination.com/search/document/6f38de391b242102/prefixquery_vs_wildc
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+0001raboo
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
24 matches
Mail list logo
