On Fri, 23 Dec 2005 11:01:52 +0000 (GMT)
eks dev <[EMAIL PROTECTED]> wrote:
> To put it another way, Filter forces us to use BitSet,
> which is rather inefficient way to store a few
> documents from the big collection.
I cannot comment on your suggestion, but I think the current filter
should probably be replaced by a more general solution.
(I haven't had the time to read the lucene mailing for quite some time
so this has probably been discussed before.)
The sort extensions already provide a cached list of document values. So
if I'd like to filter and sort for some field (e.g. date) it would look
much more natural to me to use that list for filtering than create a
list of acceptable documents stored as a bitset or a sparse list.
So IMHO a filter (as seen by the searcher) should just provide an
interface to query the information if some document is accecpted or
refused by the filter. So the interface would look like
public interface Filter {
boolean filter(int docno);
}
The current type of bitset based filters could implement this interface
as well as other types of filter.
One could problably go one step further and allow the filter to
modify the score as well (e.g. to allow for a scoring that degrades the
score of a hit depending on it's age).
Actually I just did an extension of IndexSearcher that provides that
kind of filtering for a distance filter based on geographic coordinates.
Of course such a change would not be compatible, so my suggestion goes
far beyond the suggested change.
Morus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
