[
https://issues.apache.org/jira/browse/CASSANDRA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800139#action_12800139
]
Stu Hood commented on CASSANDRA-389:
------------------------------------
I'm fine with storing the version and other metadata in the file (like 521
begins to do), as long as the different implementations of sstables can agree
on the location of this information. For instance, the implementation in 674
stores SSTable metadata at the beginning of every block so that the sstable is
easily splittable for use by the Streaming API or by Hadoop at some point in
the future.
Perhaps version information is the one thing that should be stored outside the
file, because it can define how every other piece of metadata is stored?
> SSTable Versioning
> ------------------
>
> Key: CASSANDRA-389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-389
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Assignee: Stu Hood
> Priority: Minor
> Fix For: 0.9
>
> Attachments: 389-v3.patch, 389-v4.patch,
> 389-v5-1-rebase-v4-for-trunk.diff, 389-v5-2-add-keyspace-to-descriptor.diff,
> 389-v5-3-use-descriptor-for-streaming.diff,
> 389-v5-4-validate-parameters-for-descriptor.diff,
> 389-v5-5-special-case-to-preserve-legacy.diff, CASSANDRA-389.diff,
> CASSANDRA-389.diff
>
>
> As we continue to make changes to the on-disk format of SSTables, I propose
> we start versioning. The easiest way without breaking backwards compatibility
> is to store the version in the filename. This would allow us to figure out
> the version without looking at the SSTable data. After speaking to Jonathan
> here is the proposed example:
> <CF>-<ID>-<VERSION>-<DATA|INDEX|FILTER>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
