lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-5952) Make Version.java lenient again?
Date Tue, 16 Sep 2014 08:18:35 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-5952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14135132#comment-14135132
] 

Michael McCandless commented on LUCENE-5952:
--------------------------------------------

bq. I think we still have to restrict major to be in the valid range, otherwise the encodedValue
may overflow. So major should be between 0 and 255, right?

Ahh good, I'll do that.

bq. Just a suggestion: Can we add a fake index with a version number of "6.1.0" to see if
you correctly get IndexTooNewException and not an IAE? 

So I built this 6.1.0 index (by hacking up a trunk checkout) and CheckIndex (also on trunk)
happily checked the index without complaints!  I agree we should try to somehow test forwards
compatibility ... but I'd rather explore that on a separate issue?  I'll open one.

bq. In my opinion, we should not save index version as string at all and instead save the
"encoded value" as an (v)int.

I agree ... I'll fix Lucene46SegmentInfoWriter/Reader to write as int ... I think I'll use
separate vInts: I don't like tying this "encoded format" (stuffing 4 ints that are actually
bytes into 1 int) to the index format.

> 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
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message