[
https://issues.apache.org/jira/browse/LUCENE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724452#action_12724452
]
Michael McCandless commented on LUCENE-1461:
--------------------------------------------
OK, patch looks good Uwe!
Having this filter just always take deletions into account is the safe
solution; presumably the added performance cost is OK since this filter is so
fast to begin with.
Longer term I think we need a cleaner way to ask a Scorer to "carry out"
deletions & filtering, and have it more optimally delegate that request to its
sub-scorers as needed.
One corner case issue: if I eg make a newShortRange w/ lowerVal ==
Short.MAX_VALUE and includeLower=false, which should match no docs, I think in
this case you overflow short in computing inclusiveLowerPoint and thus match
possibly many docs incorrectly? (Same for byte/int/long).
> 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-1461.patch, LUCENE-1461.patch, LUCENE-1461.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: [email protected]
For additional commands, e-mail: [email protected]