Continuing down the path of modularizing Elasticsearch we are down to the last hurdle to eliminate Lucene split packages from the codebase - LazySoftDeletesDirectoryReaderWrapper [1]. This class is a version of Lucene's SoftDeletesDirectoryReaderWrapper [2], but very specific to Elasticsearch's use case.
Similarly to SoftDeletesDirectoryReaderWrapper, we have a long-lived FilterDirectoryReader and we need a similar DelegatingCacheHelper behaviour. To support building long-lived readers without IndexReader to delegate caching to, would it be acceptable for us to refactor SoftDeletesDirectoryReaderWrapper, such that its caching behaviour is moved into specialized versions of the FilterReaders? For example, one approach would be to extend FilterDirectoryReader [3] into a LastingFilterDirectoryReader with a baked-in delegating cache behaviour. Similarly, for the purpose of both SoftDeleteDirectoryReaders implementations, we'd add a specialization of FilterLeafReader [4] and FilterCodecReader [5] with the same long-lived cache behaviour. If this approach is not suitable, is there another better alternative? Thanks, Nikola [1] https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/apache/lucene/index/LazySoftDeletesDirectoryReaderWrapper.java [2] https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/index/SoftDeletesDirectoryReaderWrapper.java [3] https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/index/FilterDirectoryReader.java [4] https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/index/FilterLeafReader.java [5] https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/index/FilterCodecReader.java
