You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Alexander Staubo <za...@byzantine.no> on 2004/05/09 08:07:14 UTC

Exact match detection

I need to detect exact matches. For example, if the query is "foo 
bar", a document matching both terms "foo" and "bar" is considered an 
exact match; and everything else is considered an inexact match.

Obviously a union with "+foo +bar" would work, but for performance 
reasons I need to avoid multiple queries.

Lucene's largely undocumented similarity/scoring system looks 
intricate enough that deconstructing a score value after the fact 
isn't possible in a reliable and portable (ie., across Lucene versions 
and varying scoring algorithm implementations) manner.

If it helps, I am not using term boosting.

Alexander.

---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Re: Exact match detection

Posted by Ype Kingma <yk...@xs4all.nl>.
On Sunday 09 May 2004 08:07, Alexander Staubo wrote:
> I need to detect exact matches. For example, if the query is "foo
> bar", a document matching both terms "foo" and "bar" is considered an
> exact match; and everything else is considered an inexact match.
>
> Obviously a union with "+foo +bar" would work, but for performance
> reasons I need to avoid multiple queries.

The scoring layer is thin, and the underlying exact match implementation
is pretty efficient. In case you are not interested in the
score, you can use the lower level searching API, and use your
own document collector that ignores the score:

See the search() method here:
http://jakarta.apache.org/lucene/docs/api/org/apache/lucene/search/Searcher.html
and the HitCollector:
http://jakarta.apache.org/lucene/docs/api/org/apache/lucene/search/HitCollector.html

Ignoring the score is a only slightly wasteful, because the scoring layer is much
faster than the disk i/o's needed for search, so rolling your own search
method is normally not worthwhile for speed.

You can construct the Query either using query the parser, or do it yourself,
in this case as a BooleanQuery containing two required TermQuery's,
one for "foo" and one for "bar".

For best performance, don't use the collected document nrs until after the search.

Evt. also check out the Lucene wiki for some articles with examples
on how to use the Lucene API.

Good luck,
Ype


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org