[
https://issues.apache.org/jira/browse/CASSANDRA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748514#action_12748514
]
Stu Hood commented on CASSANDRA-389:
------------------------------------
> any version that is not the current version. (I used "z")
Ahhh, I see what you mean. This patch doesn't actually implement handling for
the different versions. In the future, when we need to make non-compatible
changes to the disk format, we'll increment the version, and either:
* Add conditionals all over the place to handle older versions differently
(yuck),
* Subclass SSTableReader/Writer for the new version, and modify the factory
functions to return different reader subclasses per version.
> having "legacy" be distinguished from "current" is probably a mistake since
> you then have to special case it.
You're right. Since there are no file format differences between the LEGACY and
CURRENT versions, they should both be "a". I'll update the patch.
> SSTable Versioning
> ------------------
>
> Key: CASSANDRA-389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-389
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 0.4
> Reporter: Chris Goffinet
> Assignee: Stu Hood
> Priority: Minor
> Fix For: 0.4
>
> Attachments: 389-v3.patch, 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.
