[
https://issues.apache.org/jira/browse/LUCENE-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599709#action_12599709
]
Paul Elschot commented on LUCENE-1187:
--------------------------------------
While considering DefaultDocIdSet as a class, I thought that perhaps a better
way would be to add a method to class Filter that takes the usual DocIdSet and
provides the DocIdSet that should be used for caching, for example in
CachingWrapperFilter. Sth like this:
{code}
public class Filter {
... the abstract bits() deprecated method ... ;
public DocIdSet getDocIdSet(IndexReader reader) {
// unchanged implementation for now. to become abstract later.
}
public DocIdSet getDocIdSetForCache(IndexReader reader) {
// Use a default implementation here that provides a tradeoff for caching,
// fairly compact when possible, but still fast.
// For the moment this could be close to the code of the finalResult()
method
// mentioned above:
DocIdSet result = getDocIdSet(reader);
if (!(result instanceof SortedVIntList))
and (result.cardinality() < (reader.maxDoc() / 9))) {
return new SortedVIntList(result);
}
return result;
}
{code}
(One minor problem with this is that DocIdSet does not have a cardinality()
method
and that SortedVIntList does not have a constructor for a DocIdSet.)
The question is: how about adding such a getDocIdSetForCache() method to Filter?
Or is there a better place for this functionality, for example in
CachingWrapperFilter?
> Things to be done now that Filter is independent from BitSet
> ------------------------------------------------------------
>
> Key: LUCENE-1187
> URL: https://issues.apache.org/jira/browse/LUCENE-1187
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/*, Search
> Reporter: Paul Elschot
> Assignee: Michael Busch
> Priority: Minor
> Fix For: 2.4
>
> Attachments: BooleanFilter20080325.patch,
> ChainedFilterAndCachingFilterTest.patch, Contrib20080325.patch,
> Contrib20080326.patch, Contrib20080427.patch, javadocsZero2Match.patch,
> lucene-1187.patch, lucene-1187.patch, OpenBitSetDISI-20080322.patch
>
>
> (Aside: where is the documentation on how to mark up text in jira comments?)
> The following things are left over after LUCENE-584 :
> For Lucene 3.0 Filter.bits() will have to be removed.
> There is a CHECKME in IndexSearcher about using ConjunctionScorer to have the
> boolean behaviour of a Filter.
> I have not looked into Filter caching yet, but I suppose there will be some
> room for improvement there.
> Iirc the current core has moved to use OpenBitSetFilter and that is probably
> what is being cached.
> In some cases it might be better to cache a SortedVIntList instead.
> Boolean logic on DocIdSetIterator is already available for Scorers (that
> inherit from DocIdSetIterator) in the search package. This is currently
> implemented by ConjunctionScorer, DisjunctionSumScorer,
> ReqOptSumScorer and ReqExclScorer.
> Boolean logic on BitSets is available in contrib/misc and contrib/queries
> DisjunctionSumScorer calls score() on its subscorers before the score value
> actually needed.
> This could be a reason to introduce a DisjunctionDocIdSetIterator, perhaps as
> a superclass of DisjunctionSumScorer.
> To fully implement non scoring queries a TermDocIdSetIterator will be needed,
> perhaps as a superclass of TermScorer.
> The javadocs in org.apache.lucene.search using matching vs non-zero score:
> I'll investigate this soon, and provide a patch when necessary.
> An early version of the patches of LUCENE-584 contained a class Matcher,
> that differs from the current DocIdSet in that Matcher has an explain()
> method.
> It remains to be seen whether such a Matcher could be useful between
> DocIdSet and Scorer.
> The semantics of scorer.skipTo(scorer.doc()) was discussed briefly.
> This was also discussed at another issue recently, so perhaps it is wortwhile
> to open a separate issue for this.
> Skipping on a SortedVIntList is done using linear search, this could be
> improved by adding multilevel skiplist info much like in the Lucene index for
> documents containing a term.
> One comment by me of 3 Dec 2008:
> A few complete (test) classes are deprecated, it might be good to add the
> target release for removal there.
--
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]
