[
https://issues.apache.org/jira/browse/SOLR-16017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494800#comment-17494800
]
Mike Drob commented on SOLR-16017:
----------------------------------
I'm of two minds here...
If we end up deciding that we want to backports the segment cache feature from
10.0 to 9.1 or whatever, then that means this needs to also be back ported
separately. And the same is true for anybody maintaining their own fork - and
this small innocuous looking commit is the sort of thing that's easy to miss
when you don't realize it exists.
But if there is some other feature that relies on the bootstrap hook, then it
wouldn't make sense to block that on the whole segment-aware cache change,
since that can get stuck in review purgatory. AFIUI, there is not such a
feature waiting currently, but I don't know the universe of contributions that
exist.
The reason I like putting the feature hooks together with the features
themselves is because often I don't know what the correct API is until I've
actually implemented something. I'll have a rough idea, but maybe there will be
nuance I hadn't initially considered. Fortunately, it sounds like you've
already gone through those stages, so I have reason to trust that this change
is sufficient, but it still feels very abstract to me.
So I'm not against this change, I'm just leaning a little bit on the inertia of
a code base at rest. It's probably safe, and it there need to be refinements,
we can pick them up as part of the thorough review that I'm sure your next
feature will have. :)
> Allow first registered SolrIndexSearcher to inform its configured caches
> ------------------------------------------------------------------------
>
> Key: SOLR-16017
> URL: https://issues.apache.org/jira/browse/SOLR-16017
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Affects Versions: main (10.0)
> Reporter: Michael Gibney
> Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Each configured cache is currently informed of its associated
> SolrIndexSearcher when SolrCore calls the {{SolrIndexSearcher.warm(...)}},
> which in turn calls {{SolrCache.warm(...)}}, passing the searcher as an
> argument.
> It is inconsistent that caches are informed of subsequent searchers, but not
> of the first registered searcher. A note on
> [SolrCache.warm|https://github.com/apache/solr/blob/9903d00b0fb6216f836bb580f42d0081b7b41584/solr/core/src/java/org/apache/solr/search/SolrCache.java#L144-L150]
> suggests the possibility of providing the SolrIndexSearcher on
> cache.init(...). That seems reasonable to me, and would be one way to resolve
> the current inconsistency. But that would likely constitute a major change,
> perhaps involving a change in the SolrCache plugin API, and the
> responsibility of each cache to maintain its own reference to its associated
> searcher.
> Another way to resolve the current inconsistency would be to introduce a
> method to (analogous to {{warm(...)}}) that the first registered
> SolrIndexSearcher could use to inform its caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
