[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481734
]
Paul Elschot commented on LUCENE-584:
-------------------------------------
Hoss,
>Paul: I notice Filter.getMatcher returns null, and IndexSearcher tests for
>that and uses
> it to decide whether or not to iterator over the (non null) Matcher, or over
> the BitSet
> from Filter.bits. is there any reason that logic can't be put in getMatcher,
> so that if
> subclasses of Filter don't override the getMatcher method it will call bits
> and then
> return a Matcher that iterates over the set Bits?
Two reasons:
- uncertainty over performance of a Matcher instead of a BitSet,
- this way backward compatibility very easily guaranteed.
There is also LUCENE-730, which may interfere with the removal of BitSet,
since it allows documents to be scored out of order. However, LUCENE-730
should only be used at the top level of a query search and without a Filter.
I cannot think of an actual case in which there might be interference, but
I may not have not looked into that deep enough.
> we could even change Filter.bits so it's no longer abstract ... it could have
> an implementation that would call getMatcher, and iterate over all of the
> matched
> docs setting bits on a BitSet that is then returned ... the class would still
> be
> abstract, and the class javadocs would make it clear that subclasses must
> override
> at least one of the methods...
I must say that creating a BitSet from a Matcher never occurred to me.
Anyway, when Filter.bits() is deprecated I have no preference about how
it is actually removed.
> 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: BitsMatcher.java, 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
