[
https://issues.apache.org/jira/browse/LUCENE-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244028#comment-16244028
]
Robert Muir commented on LUCENE-8042:
-------------------------------------
Also i would still like to see if we can make this simply a boolean method,
isCacheable.
I am concerned that API decisions are being made on broken assumptions (eg.
LUCENE-8017). Such function queries that depend on the documents score can
never be cached, ever, because they users can override *statistics methods in
IndexSearcher and implement distributed search, or feed numbers from a random
number generator, or whatever the hell they want. So it is actually false that
such queries depend on the whole index, they are simply unsafe to cache.
So, I'd like to put an end to the theoretical discussion of top-level caching
here, right now, and make the api minimal and something we can live with.
> Add SegmentCachable interface
> -----------------------------
>
> Key: LUCENE-8042
> URL: https://issues.apache.org/jira/browse/LUCENE-8042
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Alan Woodward
> Attachments: LUCENE-8042.patch, LUCENE-8042.patch, LUCENE-8042.patch
>
>
> Following LUCENE-8017, I tried to add a getCacheHelper(LeafReaderContext)
> method to DoubleValuesSource so that Weights that use DVS can delegate on.
> This ended up with the same method being added to LongValuesSource, and some
> of the similar objects in spatial-extras. I think it makes sense to abstract
> this out into a separate SegmentCachable interface.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
