apache
SOLR-15060: Introduce DelegatingDirectoryFactory.
For the description, see https://issues.apache.org/jira/browse/SOLR-15060
This PR adds a new method get(String path, DirContext dirContext, String rawLockType, Function<Directory, Directory> wrappingFunction) in DirectoryFactory, with a new wrappingFunction parameter. The existing get(String path, DirContext dirContext, String rawLockType) calls the new one with Function.identity().
I wonder if this change should be 8x or 9x.
The PR is about introducing a low level utility that we expect will be useful for custom DirectoryFactory implementations that we don't even have yet. It's the kind of thing that many of us wouldn't of even created a separate PR for -- it'd show up in a larger PR that introduces the first user of the utility. It's not even worth a CHANGES.txt entry IMO; there's always the commit message. As long as there is no user of this code yet, I'd prefer that we don't merge this yet. Perhaps we may find that the abstraction here isn't quite right.
RE master (9) vs 8x... If we wait till BlobDirectory, it'd almost certainly be 9. If we don't, ehh... I'd just do 9.
Actually I'll need that to simplify the code in BlobDirectory. So based on your remark David, I should rather integrate this code in BlobDirectory code and close this Jira issue.
An in-between is to leave this issue open until the BlobDirectory is much more ready. It may change in the mean time; who knows. I do like the notion of committing separate pieces instead of one feature!