lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Elschot (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-584) Decouple Filter from BitSet
Date Wed, 25 Jul 2007 10:21:31 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Paul Elschot updated LUCENE-584:
--------------------------------

    Attachment: DefaultMatcher20070725.patch

This DefaultMatcher2007072.patch adds a default Matcher to be used in Filter instead of the
BitSet . It contains static methods that create a default Matcher from a BitSet and from an
OpenBitSet. The patch also add OpenBitSet to org.apache.lucene.util; it was taken from a recent
solr revision.

In this way the deprecation of Filter.bits(IndexReader) can be done by replacing implementations
of that method by Filter.getMatcher(IndexReader) and adding the above default Matcher in the
return statement:
return DefaultMatcher.defaultMatcher(bits);

The idea is to have this hook available so that a sensible default Matcher is easily available,
that can also be adapted to use better Matcher implementations when these become available.
The current implementation uses a SortedVIntList when it is smaller than an (Open)BitSet.

I have begun introducing the default matcher in my working copy of the core, but as expected,
that turns out to be quite a bit of work.
Before I continue with that, I'd like to have comments on this default matcher approach.


> Decouple Filter from BitSet
> ---------------------------
>
>                 Key: LUCENE-584
>                 URL: https://issues.apache.org/jira/browse/LUCENE-584
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.0.1
>            Reporter: Peter Schäfer
>            Priority: Minor
>         Attachments: bench-diff.txt, bench-diff.txt, BitsMatcher.java, DefaultMatcher20070725.patch,
Filter-20060628.patch, HitCollector-20060628.patch, IndexSearcher-20060628.patch, MatchCollector.java,
Matcher.java, Matcher20070226.patch, Scorer-20060628.patch, Searchable-20060628.patch, Searcher-20060628.patch,
Some Matchers.zip, SortedVIntList.java, TestSortedVIntList.java
>
>
> {code}
> package org.apache.lucene.search;
> public abstract class Filter implements java.io.Serializable 
> {
>   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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message