[
https://issues.apache.org/jira/browse/LUCENE-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955162#comment-13955162
]
Uwe Schindler commented on LUCENE-2446:
---------------------------------------
Robert, sorry if I throwed some unrelated ideas in here: My idea here has not
much to do with the stuffs here. It just came into my mind when I was seeing
the validate() method which made me afraid.
Now just throwing in something, which does not have to affect *you* while
implementing checksumming - just think about it as a separate issue, inspired
by this one:
{panel:title=Uwe's unrelated
idea|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
In general CheckIndex as a separate class is wrong in my opinion. Especially if
it does checks not valid for all codecs (using instanceof checks in CheckIndex
code - horrible). A really good CheckIndex should work like fsck - implemented
by the file system driver + filesystem code. So the checks currently done by
CheckIndex should be done by the codecs (only general checks may work on top -
like numDocs checks, etc.)
{panel}
Now back to this issue: To come back to the initial suggestion: validate =>
checkIntegrity. What do you think?
> Add checksums to Lucene segment files
> -------------------------------------
>
> Key: LUCENE-2446
> URL: https://issues.apache.org/jira/browse/LUCENE-2446
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
> Reporter: Lance Norskog
> Labels: checksum
> Attachments: LUCENE-2446.patch
>
>
> It would be useful for the different files in a Lucene index to include
> checksums. This would make it easy to spot corruption while copying index
> files around; the various cloud efforts assume many more data-copying
> operations than older single-index implementations.
> This feature might be much easier to implement if all index files are created
> in a sequential fashion. This issue therefore depends on [LUCENE-2373].
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
