magibney commented on PR #1351: URL: https://github.com/apache/solr/pull/1351#issuecomment-1434945785
There are several possibilities with how to proceed here: 1. We consider node-level cache support to be fundamentally valuable enough in its own right to commit this as a "hook", initially without the `ThinCache` proof-of-concept that leverages the functionality, updating the refguide to cover node-level cache configuration. 2. We proceed to commit this with the current proof-of-concept `ThinCache` implementation (building out tests and refguide accordingly). 3. We close this PR, and come back to it when it can be introduced alongside a less naive implementation leveraging this functionality. My preferred approach would be the first of these: to revert 916806b39e0f39424fec0a6946e85486a65fc422 (the introduction of the `ThinCache` proof-of-concept) and only commit the minor infrastructural changes that enable configuring node-level caches, and enable searcher-aware core caches (a prerequisite for core/searcher-scoped keys at the node level). The benefit of this approach would be that it would support independent experimentation with pluggable cache impls leveraging a node-level approach, allowing implementations to be more fully developed before if/when being contributed to Solr core. The downside of option 2 would be that if people start using the naive `ThinCache` proof-of-concept, it makes upgrade paths more challenging (and comes with the risk of presenting a relatively new implementation when there's very little downside to providing the opportunity to approach the addition of new cache impls in a more deliberate way). The pluggable nature of the `ThinCache` impl means that anyone who wants to run it could easily compile it themselves (as a plugin). Option 3 is totally fine too, and would probably be my second choice (after option 1). The upside of this approach would be that if the interface needs to change (for some reason?) to support a more robust cache implementation, the node-level and searcher-aware changes could arrive more fully-formed (though tbh what's needed here is quite straightforward and I'd be very surprised if it needed to change). The downside of option 3 is that (obviously) folks who wanted to experiment with this approach would have to do so on a custom branch of Solr, making experimentation with a node-level cache approach more difficult for many people (and potentially resulting in divergent approaches to common configuration, which would need to be reconciled). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
