[ 
https://issues.apache.org/jira/browse/LUCENE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650936#action_12650936
 ] 

Uwe Schindler commented on LUCENE-1461:
---------------------------------------

The RangeQuery still relies on the sort order of terms (this is how it works). 
For storing terms with lower precision you have two possiblities:

a) use another field name for each precision
b) prefix the terms with a precision marker. The prefix is important for the 
sort order, so that all terms of one precision are in one "bunch" and not 
distributed between higher precsion terms.

The first version of my TrieRangeQuery was invented before the RangeFilter 
occurred first in Lucene. This version did exactly what was proposed here: 
combining more range queries with OR.

For my last implementation, based on filters I did not use a BooleanQuery with 
OR'ed ranges because of resource usage: Each RangeFilter needs an OpenBitSet 
instance, and all of them must be OR'ed during query execution. Using only one 
OpenBitSet for all range parts is more effective, I think. I am currently 
working on including my extension to the contrib-query package. I refactored 
the code a little bit, so the TrieRangeFilter is now separated from the query 
(and because of that could be used with e.g. filter caching). I think, I will 
start n issue this afternoon.

> 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, 
> LUCENE-1461b.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]

Reply via email to