[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Elschot updated LUCENE-584:
--------------------------------
Attachment: Matcher-20070905-3core.patch
Matcher-20070905-2default.patch
Matcher-20070905-1ground.patch
This time (20070905), as indicated in the previous post, a set of patches that
add MatchFilter as the new superclass of Filter. Backward compatibility is
quite good, no changes at all are necessary in contrib.
In the 1ground patch, the current core API is moved from Filter to MatchFilter.
Since Filter is a subclass of MatchFilter, I do not expect backward
compatibility issues with this, but it is a quite extensive API change.
In the 2default patch, some support for MatchFilter caching was added in
classes DefaultMatcher and MatcherProvider. OpenBitSet and some support for
that was added from solr here, but OpenBitSet is not used (yet). SortedVIntList
is also added, and this is used for caching in CachingWrapperFilter as below.
In the 3core patch, this caching support is used in CachingWrapperFilter. See
also java-dev of yesterday and today for a fixed thread safety problem there.
The remainder of the core code is also adapted to the use of Matcher in the
3core patch. ConstantScoreQuery is a nice example.
I also added the Apache Licence to all new files.
All tests pass with the patches applied, core and contrib.
Quite a bit of javadoc is included, and the javadocs build with only one
(unrelated) warning.
These 3 patches modify 35 source code files, so please tread carefully. They
were generated against revision 573048.
I did some local svn mv, svn add, and svn rm, and I hope I got
that right in the end. In case the patches do not apply cleanly, please holler.
I will remove my previous patch set in a week or so.
> 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,
> Matcher-20070905-1ground.patch, Matcher-20070905-2default.patch,
> Matcher-20070905-3core.patch, 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]
