[
https://issues.apache.org/jira/browse/SOLR-15356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17325536#comment-17325536
]
Adrien Grand commented on SOLR-15356:
-------------------------------------
It's an interesting case. With {{UninvertDocValuesMergePolicyFactory}}, you end
up with doc values on all merged segments, but flushed segments still uninvert.
This is a setup that would generally confuse Lucene, but the reason why it
works here is because the index reader is always wrapped with
{{UninvertingReader}} at search time, so that all segments appear to have doc
values.
I just read the original issue where this was introduced (SOLR-10046) which
suggests that this merge policy was mostly introduced as a way to help users
start leveraging doc values on their existing indices. Would it be acceptable
to reject using this merge policy on new indices created as of Solr 9.0, and
require users to configure doc values on fields where they need them, while
keeping it working on 8.x indices that have been upgraded to Solr 9.0?
> Lucene requires consistency across fields
> -----------------------------------------
>
> Key: SOLR-15356
> URL: https://issues.apache.org/jira/browse/SOLR-15356
> Project: Solr
> Issue Type: Task
> Components: Schema and Analysis
> Affects Versions: main (9.0)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Blocker
>
> LUCENE-9334 requires more consistency across fields (Lucene 9). We must
> accommodate this in some tests which started failing. Example:
> org.apache.solr.index.UninvertDocValuesMergePolicyTest
> "cannot change field "string_add_dv_later" from doc values type=NONE to
> inconsistent doc values type=SORTED"
> From
> org.apache.lucene.index.FieldInfo.verifySameDocValuesType(FieldInfo.java:271)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
