[ https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516502 ]
Paul Elschot commented on LUCENE-584: ------------------------------------- Some more remarks on the 20070730 patches. To recap, this introduces Matcher as a superclass of Scorer to take the role that BitSet currently has in Filter. The total number of java files changed/added by these patches is 47, so some extra care will be needed. The following issues are still pending: What approach should be taken for the API change to Filter (see above, 2 comments up)? I'd like to get all test cases to pass again. TestRemoteCachingWrapperFilter still does not pass, and I don't know why. For xml-query-parser in contrib I'd like to know in which direction to proceed (see 1 comment up). Does it make sense to try and get the TestQueryTemplateManager test to pass again? The ..default.. patch has taken OpenBitSet and friends from solr to have a default implementation. However, I have not checked whether there is unused code in there, so some trimming may still be appropriate. Once these issues have been resolved far enough, I would recommend to introduce this shortly after a release so there is some time to let things settle. > 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, > Matcher1-ground-20070730.patch, Matcher2-default-20070730.patch, > Matcher3-core-20070730.patch, Matcher4-contrib-misc-20070730.patch, > Matcher5-contrib-queries-20070730.patch, Matcher6-contrib-xml-20070730.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]