[
https://issues.apache.org/jira/browse/LUCENE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14135205#comment-14135205
]
Michael McCandless commented on LUCENE-5952:
--------------------------------------------
bq. Yeah, we should maybe add a method to Version that writes itsself to a
DataOutput: Version.writeVersion(DataOutput) and Version.readVersion(DataInput).
I didn't like that option either, because this (serialization formats) is not
Version's burden to bear.
E.g. what if we want to later change that format it wrote? We already put this
burden on the codec formats, so I think leaving the burden in
Lucene46SegmentInfoFormat is the right place...
bq. In any case, this is a separate issue, because it involves a index format
change, that we should not do in 4.10.1. I would suggest to change this for the
coming 5.0.
I don't think this should wait for 5.0? I think it's dangerous/fragile relying
on string parsing to rebuild the Version when we open IndexReaders...
> Make Version.java lenient again?
> --------------------------------
>
> Key: LUCENE-5952
> URL: https://issues.apache.org/jira/browse/LUCENE-5952
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 4.10
> Reporter: Michael McCandless
> Priority: Blocker
> Fix For: 4.10.1, 4.11, 5.0
>
> Attachments: LUCENE-5952.patch, LUCENE-5952.patch
>
>
> As discussed on the dev list, it's spooky how Version.java tries to fully
> parse the incoming version string ... and then throw exceptions that lack
> details about what invalid value it received, which file contained the
> invalid value, etc.
> It also seems too low level to be checking versions (e.g. is not future proof
> for when 4.10 is passed a 5.x index by accident), and seems redundant with
> the codec headers we already have for checking versions?
> Should we just go back to lenient parsing?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
