lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Busch (JIRA)" <>
Subject [jira] Updated: (LUCENE-584) Decouple Filter from BitSet
Date Fri, 01 Feb 2008 03:55:16 GMT


Michael Busch updated LUCENE-584:

    Attachment: lucene-584-take5-part2.patch

OK here's a new version of the patch.

It's based on the take4 patch with the following changes:
- removed BitSetFilter
- added getBitSet() method to DocIdBitSet
- added Paul's Test20080111.patch
- changed TestScorerPerf to use a DocIdBitSet
- changed ChainedFilterTest, CachedFilterBuilder, TestRemoteSearchable 
to use QueryWrapperFilter instead of deprecated QueryFilter

- As mentioned in my previous comment it's not possible to wrap a 
CachingWrapperFilter around a BitSetFilter and then retrieve the BitSet 
from the CachingWrapperFilter. That's the reason why I removed 
BitSetFilter and added the getBitSet() method to DocIdBitSet instead.
So you can do something like this:
DocIdSet docIdSet = filter.getDocIdSet();
if (docIdSet instanceof DocIdBitSet) {
  BitSet bits = ((DocIdBitSet) docIdSet).getBitSet();
- I didn't include Paul's ContribQueries20080111.patch because it only 
changes some contrib filters to extend BitSetFilter instead of Filter.
- I like Eks' suggestion of implementing the BooleanFilter in a way that 
it can use any DocIdSetIterator and optimize special cases, when DocIdSet 
is a DocIdBitSet, OpenBitSet, etc. We should do this with a different JIRA 
issue - this patch is already big enough.

All core & contrib tests pass.

I'd like to commit this in a couple of days if nobody objects.

> Decouple Filter from BitSet
> ---------------------------
>                 Key: LUCENE-584
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.0.1
>            Reporter: Peter Schäfer
>            Assignee: Michael Busch
>            Priority: Minor
>             Fix For: 2.4
>         Attachments: bench-diff.txt, bench-diff.txt, ContribQueries20080111.patch, lucene-584-take2.patch,
lucene-584-take3-part1.patch, lucene-584-take3-part2.patch, lucene-584-take4-part1.patch,
lucene-584-take4-part2.patch, lucene-584-take5-part1.patch, lucene-584-take5-part2.patch,
lucene-584.patch, Matcher-20070905-2default.patch, Matcher-20070905-3core.patch, Matcher-20071122-1ground.patch,
Some, Test20080111.patch
> {code}
> package;
> public abstract class Filter implements 
> {
>   public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
> }
> public interface AbstractBitSet 
> {
>   public boolean get(int index);
> }
> {code}
> It would be useful if the method =Filter.bits()= returned an abstract interface, instead
of =java.util.BitSet=.
> Use case: there is a very large index, and, depending on the user's privileges, only
a small portion of the index is actually visible.
> Sparsely populated =java.util.BitSet=s are not efficient and waste lots of memory. It
would be desirable to have an alternative BitSet implementation with smaller memory footprint.
> Though it _is_ possibly to derive classes from =java.util.BitSet=, it was obviously not
designed for that purpose.
> That's why I propose to use an interface instead. The default implementation could still
delegate to =java.util.BitSet=.

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:
For additional commands, e-mail:

View raw message