[
https://issues.apache.org/jira/browse/LUCENE-2468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869369#action_12869369
]
Shay Banon commented on LUCENE-2468:
------------------------------------
bq. So... why not do this in CachingWrapper/SpanFilter, but, instead of
discarding the cache entry when deletions must be enforced, we dynamically
apply the deletions? (I think we could use FilteredDocIdSet).
Yea, that would work well. You will need to somehow still know when to enable
or disable this based on the filter you use (it should basically only be
enabled ones that are passed to constant score... .
bq. Really... we need a more generic solution here (but, it's a much bigger
change), where somehow in creating the scorer per-segment we dynamically
determine who/where the deletions are enforced. A Filter need not care about
deletions if it's AND'd w/ a query that already enforces the deletions.
Agreed. As I see it, caching based on IndexReader is key in Lucene, and with
NRT, it should feel the same way as it is without it. NRT should not change the
way you build your system.
> reopen on NRT reader should share readers w/ unchanged segments
> ---------------------------------------------------------------
>
> Key: LUCENE-2468
> URL: https://issues.apache.org/jira/browse/LUCENE-2468
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Yonik Seeley
> Assignee: Michael McCandless
> Attachments: CacheTest.java, DeletionAwareConstantScoreQuery.java,
> LUCENE-2468.patch, LUCENE-2468.patch
>
>
> A repoen on an NRT reader doesn't seem to share readers for those segments
> that are unchanged.
> http://search.lucidimagination.com/search/document/9f0335d480d2e637/nrt_and_caching_based_on_indexreader
--
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]
