[
https://issues.apache.org/jira/browse/LUCENE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler reopened LUCENE-1461:
-----------------------------------
Assignee: Uwe Schindler (was: Michael McCandless)
I reopened the wrong issue :-(
The class to handle is FieldCacheRangeFilter! Here, why reopen:
This Filter is really cool on iterating on the FieldCache for StringIndex and
can be even faster for ranges, that are int/float/double/... - so why not
retrofit to our new naming-convention and extend:
- FieldCacheRangeFilter.newTermRange()
- FieldCacheRangeFilter.newByteRange()
- FieldCacheRangeFilter.newShortRange()
- FieldCacheRangeFilter.newIntRange()
- ...
It could because of that also be used on "old" int/long fields of dates, if a
good parser is given (parser that does SimpleDateFormat -> long -> FieldCache
-> direct comparison on this raw numbers). I would try to extend this to all
types and it can be faster than TrieRange, if the range is already in
FieldCache!
was (Author: thetaphi):
Is this Filter really needed anymore?
If yes, why not create an FieldCacheRangeFilter that can handle any data type
from FieldCache:
- FieldCacheRangeFilter.newTermRange()
- FieldCacheRangeFilter.newByteRange()
- FieldCacheRangeFilter.newShortRange()
- FieldCacheRangeFilter.newIntRange()
- ...
> 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
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: DisjointMultiFilter.java, FieldCacheRangeFilter.patch,
> LUCENE-1461.patch, LUCENE-1461a.patch, LUCENE-1461b.patch,
> LUCENE-1461c.patch, RangeMultiFilter.java, RangeMultiFilter.java,
> TermMultiFilter.java, TestFieldCacheRangeFilter.patch
>
>
> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
