[
https://issues.apache.org/jira/browse/LUCENE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381169#comment-14381169
]
Hoss Man commented on LUCENE-6370:
----------------------------------
I don't know enough about SearchManager to comment on the specifics of that
assertion or your patch, but regarding this comment...
bq. 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:
I believe there is a third option here, which is to open an UnivertingReader on
the original index, and use that reader to addIndex() into a new writer,
creating the docvalues in the process.
I know Toke has used an approach similar to this (in his case he used the
stored fields, not hte indexed values - not sure why off the top of my head) on
a non-trivial index, and made his code available under the ASL2...
https://sbdevel.wordpress.com/2014/12/15/changing-field-type-in-lucenesolr/
https://github.com/netarchivesuite/dvenabler
> UninvertingReader cannot be used with ControlledRealTimeReopenThread
> --------------------------------------------------------------------
>
> Key: LUCENE-6370
> URL: https://issues.apache.org/jira/browse/LUCENE-6370
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 5.0
> Reporter: Dave Borowitz
> Attachments: LUCENE-6370.patch
>
>
> 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{Directory,Leaf}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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
