[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557814#action_12557814
]
Paul Elschot commented on LUCENE-584:
-------------------------------------
As for PrefixGenerator:
in my (up to date) trunk directory, this command: find . -name
'*PrefixGenerator*'
only gave this result:
./build/classes/java/org/apache/lucene/search/PrefixGenerator.class
and that disappeared after ant clean.
It seems that the source class was removed from the trunk.
{quote}
I think that it should be straightforward for users having filters that use
BitSets to wrap the new DocIdBitSet around the BitSet, just as Filter currently
does for backwards compatibility?
{quote}
BitSetFilter would inherit from Filter, and have an abstract bits() method, not
deprecated.
This would be useful for people that don't what to move to OpenBitSet yet.
A rename (and maybe a package change) from Filter to BitSetFilter should be
sufficient
in their code to get rid of the deprecation warning for Filter.bits().
OpenBitSetFilter similar, and that could be used in a few places in the patch
iirc.
The javadoc changes I meant came with Matcher and use 'match' consistently for
documents
that are collected during a query search.
> 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
> Assignee: Michael Busch
> Priority: Minor
> Fix For: 2.4
>
> Attachments: bench-diff.txt, bench-diff.txt, lucene-584-take2.patch,
> lucene-584-take3-part1.patch, lucene-584-take3-part2.patch, lucene-584.patch,
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
> Matcher-20071122-1ground.patch, Some Matchers.zip
>
>
> {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]
