[
https://issues.apache.org/jira/browse/LUCENE-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497622#comment-13497622
]
Robert Muir commented on LUCENE-4558:
-------------------------------------
so the compression format byte is replaced by string you passed in the codec
header...
(sorry i havent fully thought about it and I'm not listing objections, just
thinking to be careful) because:
* I see lucene41 stored fields impl puts a "version inside the string"
* codec header name mismatch is a corruptindexexception
As I've said before, i dont like that we put versions "inside the string" even
for Codec names.
But I think it was the right tradeoff to do: compare 4.1's format versus 4.0,
its easier that they are separate codecs i think.
We just need to be really cautious whenever putting a version inside a string
in general.
At some point in the future, Lucene40 and Lucene41 codec will be too old and we
are going to need hacks
to throw IndexFormatTooOldException and so on, so we are already in trouble
today :)
> Make CompressingStoredFieldsFormat more flexible
> ------------------------------------------------
>
> Key: LUCENE-4558
> URL: https://issues.apache.org/jira/browse/LUCENE-4558
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-4558.patch
>
>
> My plan consists in making CompressionMode an abstract class instead of an
> enum and having different codec names per CompressionMode. I think this has
> two main benefits:
> - it makes Lucene41StoredFieldsFormat cleaner (no need to write a
> CompressionMode id),
> - it allows for custom CompressionModes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]
