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
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