[
https://issues.apache.org/jira/browse/LUCENE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650685#action_12650685
]
Tim Sturge commented on LUCENE-1461:
------------------------------------
Paul,
Thanks for the updates. I'll see about toString() and hashCode() methods. Are
we settled on RangeMultiFilter as the least confusing name?
Mike, Paul,
I'll play with the lucene test infrastructure. Right now all the tests have
been in my application but I can make a clean build to try them out.
Mike,
I have a slight bias against adding RangeMultiFilter to RangeFilter due to the
slight difference in semantics. RangeMultiFilter only works on single term
fields (which should probably be mentioned in the java docs) whereas
RangeFilter works on multiple term fields as well.
While I expect more than 95% of the RangeFilter use cases are met by
RangeMultiFilter (I suspect they are primarily dates, and otherwise prices and
other numeric ranges.) I bet there are some people who really do a text range
search between "aardvark" and "antelope". Those people will unexpectedly break
if they set "useFieldCache=true" or setMethod(). I would rather we add a
comment in the RangeFilter javadocs to the effect of:
"If you have a single term field (for example a date, or a price) that is
repeatedly used in a RangeFilter with many different ranges, you should
consider using RangeMultiFilter as a faster alternative to building a
RangeFilter on this field for each query. You need to ensure that this field is
untokenized, or that it always tokenizes to a single term."
> Cached filter for a single term field
> -------------------------------------
>
> Key: LUCENE-1461
> URL: https://issues.apache.org/jira/browse/LUCENE-1461
> Project: Lucene - Java
> Issue Type: New Feature
> Reporter: Tim Sturge
> Attachments: DisjointMultiFilter.java, LUCENE-1461a.patch,
> RangeMultiFilter.java, RangeMultiFilter.java, TermMultiFilter.java
>
>
> These classes implement inexpensive range filtering over a field containing a
> single term. They do this by building an integer array of term numbers
> (storing the term->number mapping in a TreeMap) and then implementing a fast
> integer comparison based DocSetIdIterator.
> This code is currently being used to do age range filtering, but could also
> be used to do other date filtering or in any application where there need to
> be multiple filters based on the same single term field. I have an untested
> implementation of single term filtering and have considered but not yet
> implemented term set filtering (useful for location based searches) as well.
> The code here is fairly rough; it works but lacks javadocs and toString() and
> hashCode() methods etc. I'm posting it here to discover if there is other
> interest in this feature; I don't mind fixing it up but would hate to go to
> the effort if it's not going to make it into Lucene.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
