[
https://issues.apache.org/jira/browse/LUCENE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116334#comment-13116334
]
Michael McCandless commented on LUCENE-3186:
--------------------------------------------
Remember we are talking about the exception case here (app mis-uses
the API by mixing up types).
So I think a best-effort approach is fine: we "cast up" when we can,
but when we cannot we should silently drop the inconsistent values
(better, I think, than getting an unrecoverable exception on merge).
Having indexer/searcher decide what's best is an interesting
option... though, I think sorted or not should be specified in the
Field and not codec? Ie, I think that's higher up than the codec (all
codecs should be able to sort, or not, my byte[] DV field).
> DocValues type should be recored in FNX file to early fail if user specifies
> incompatible type
> ----------------------------------------------------------------------------------------------
>
> Key: LUCENE-3186
> URL: https://issues.apache.org/jira/browse/LUCENE-3186
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/index
> Affects Versions: 4.0
> Reporter: Simon Willnauer
> Assignee: Simon Willnauer
> Fix For: 4.0
>
>
> Currently segment merger fails if the docvalues type is not compatible across
> segments. We already catch this problem if somebody changes the values type
> for a field within one segment but not across segments. in order to do that
> we should record the type in the fnx fiel alone with the field numbers.
> I marked this 4.0 since it should not block the landing on trunk
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]