Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
5.0
-
None
-
None
-
None
-
New
Description
In order to sort over non-DocValues fields in 5.0 we need to use an UninvertingReader to get the old FieldCache behavior back. However, UninvertingReader cannot be (easily) used with a ControlledRealTimeReopenThread.
Specifically, the easiest way to construct a ControlledRealTimeReopenThread is with a SearcherManager. The only way I found to wire an UninvertingReader into SearcherManager is to implement a SearcherFactory that wraps the passed-in reader. Unfortunately, that runs afoul of the check in SearcherManager.getSearcher that requires "SearcherFactory must wrap exactly the provided reader". So, as long as this check is there, I simply don't see a way to use UninvertingReader with NRT functionality.
I think this is a serious issue for programs that need to be able to use NRT search features on indexes created with previous Lucene versions, for whom upgrading the index is not an easy option. If they were previously relying on sorting implicitly via FieldCache, the only ways to upgrade are:
a) rebuild the index using DocValues fields, or
b) use UninvertingReader
Right now there's a catch-22, as (a) is assumed to be not an option and (b) is broken due to this bug.
I have a hacky workaround for Gerrit Code Review up for review here:
https://gerrit-review.googlesource.com/#/c/66613/6/gerrit-lucene/src/main/java/com/google/gerrit/lucene/WrappableSearcherManager.java@191
Basically, it loosens the restriction on the newSearcher result to allow Filtered
Readers that wrap the original reader. This appears to work fine for us, and I don't see anything in UninvertingReader that would cause me to believe it doesn't work. However, I'm no expert on Lucene internals and I don't know why that identity check was there in the first place, so I may be missing something.
Please do not take that patch directly until I have gotten permission from my employer to contribute it.