[
https://issues.apache.org/jira/browse/CASSANDRA-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17432901#comment-17432901
]
Benedict Elliott Smith commented on CASSANDRA-17048:
----------------------------------------------------
Hi Jacek,
I'd be willing to be a reviewer, but I'm not sure when time will become
available for review as this patch isn't as trivial as it might first appear.
So it depends how impatient you are for review.
I do have some initial comments though, regarding upgrades:
* I would firstly prefer that we do not remove compatibility with upgrades from
3.0, at least as part of this patch. I think the project should expressly agree
when we deprecate support for upgrades from a given version, and aim to be as
permissive as possible while the maintenance burden is minimal.
* Relatedly, since we are aiming for a shippable trunk with live upgrades and
patch compatibility (and for major users to be preferably deploying trunk into
production as early as possible), the logical conclusion of this is support for
live downgrades, i.e. ensuring incompatible changes like this do not prevent an
operator from restarting the node with an earlier version of trunk. We have a
goal of enabling this across major versions as well, to ensure smooth rollout
of new versions of the software.
Both of these are items that have been touched upon in wider DISCUSS threads,
but that I don't think we have a formal project-level policy on. Depending on
your (and your colleague's) thoughts on this we might need to formulate such a
policy before this patch is merged.
_Precisely_ how to do the second item when deprecating a system table is
unclear, though there are a variety of options:
# Provide some downgrade tool to migrate data back to the earlier table;
# Make the upgrade to a new system table user-initiated, so that nodes are
easily downgradeable until this point;
# Introduce a new {{SignedBytesType}} that is compatible with {{Int32Type}} and
simply modify the schema of the existing table to use this type so that we do
not need a new system table (and downgrade only becomes impossible when the new
UUID format begins to be used)
Thoughts?
> Replace sequential sstable generation identifier with ULID
> ----------------------------------------------------------
>
> Key: CASSANDRA-17048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17048
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Replace the current sequential sstable generation identifier with ULID based.
> ULID is better because we do not need to scan the existing files to pick the
> starting number as well as we can generate globally unique identifiers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
