[
https://issues.apache.org/jira/browse/LUCENE-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16220453#comment-16220453
]
Yonik Seeley commented on LUCENE-8017:
--------------------------------------
We need something that better describes the needed context to ensure repeatable
results. isCacheable is only applicable to a single type of cache
implementation.
- some queries depend only on the segment
- some queries depend on the entire searcher (example: docfreq across segments)
- some queries depend on even more (example: global docfreq across different
servers)
- some queries actually may not be repeatable/cacheable
One could either use marker interfaces to distinguish between these:
SegmentRepeatability, SearcherRepeatability, ExternalRepeatability,
NotRepeatable
(I don't really like those names, but you get the idea). We could just
normally assume the first and mark the exceptions.
Or perhaps "SearcherInvariant" (i.e. one needs to go up to the searcher level
for results to be invariant / not change)
> FunctionRangeQuery and FunctionMatchQuery can pollute the QueryCache
> --------------------------------------------------------------------
>
> Key: LUCENE-8017
> URL: https://issues.apache.org/jira/browse/LUCENE-8017
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Alan Woodward
> Assignee: Alan Woodward
>
> The QueryCache assumes that queries will return the same set of documents
> when run over the same segment, independent of all other segments held by the
> parent IndexSearcher. However, both FunctionRangeQuery and
> FunctionMatchQuery can select hits based on score, which depend on term
> statistics over the whole index, and could therefore theoretically return
> different result sets on a given segment.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
