lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3212) Supply FilterIndexReader based on any
Date Sun, 26 Jun 2011 21:25:48 GMT


Uwe Schindler commented on LUCENE-3212:

I don't think, this issue is obsolete with LUCENE-1536:
If you have one filter thats e.g. applied for one user every time, maybe for all his queries,
it can live as long as the SegmentReader lives. So simply wrapping the IndexReader with a
Filter has much more flexibility, as its done one time on creating the IndexReader - so I
think, this filter could additionally live in contrib. If we have RandomAccessFilters, this
one and also PKIndexSplitter (which will only use this FIR and drop its own impl) can directly
use the Bits supplied by the Filter's DocIdSet.

> Supply FilterIndexReader based on any
> ---------------------------------------------------------
>                 Key: LUCENE-3212
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/index, core/search
>    Affects Versions: 4.0
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 4.0
> When coding LUCENE-2919 (PKIndexSplitter), Mike and me had the idea, how to effectively
apply filters on the lowest level (before query execution). This is very useful for e.g. security
Filters that simply hide some documents. Currently when you apply the filter after searching,
lots of useless work was done like scoring filtered documents, iterating term positions (for
> This patch will provide a FilterIndexReader subclass (4.0 only, 3.x is too complicated
to implement), that hides filtered documents by returning them in getDeletedDocs(). In contrast
to LUCENE-2919, the filtering will work on per-segment (without SlowMultiReaderWrapper), so
per segment search keeps available and reopening can be done very efficient, as the filter
is only calculated on openeing new or changed segments.
> This filter should improve use-cases where the filter can be applied one time before
all queries (like security filters) on (re-)opening the IndexReader.

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message