[
https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194621#comment-16194621
]
Sylvain Lebresne commented on CASSANDRA-13813:
----------------------------------------------
bq. I don't believe it's reasonable to keep bugs in the codebase just because
they mask out other bugs.
Just to make sure my position is clear, I'm not suggesting we leave this ticket
unsolved. What I'm suggesting is that it would be possible to forbid truly
harmful changes (droping tables and adding/removing/renaming columns; that part
is the real bug to me) while still allowing the altering of table parameters
(which actually don't seem that problematic to me on principle). Sure, it
requires adding some special casing in {{AlterTableStatement}}, but it's not
very complex either.
bq. when their cluster are unable to pick up our altered defaults, because of
our bumped hardcoded timestamps being smaller than the new ones set via ALTER
TABLE
I'm not sure I understand the problem. If user have manually and knowingly
updated some table params, my guess is that they expect (even rely on) future
changes to defaults to not override their changes. Isn't the whole point why
we've picked 0 for our hardcoded timestamp in fact?
But if there is genunine reason I'm missing that make it dangerous for user to
alter those parameters, that's certainly important to understand. I'm pretty
sure some user _have_ done it (at least to work around CASSANDRA-12701,
possibly for other reasons), and if their change is a time-bomb, we kind of owe
them to disarm that bomb.
But anyway, to sum it up, the patch lgtm from a technical level, and I'm
definitively on board with forbidding clearly harmful changes. The only
specific part I'm unsure is the "altering table parameters" part. In light of
my current understanding, it doesn't look obviously harmful (I can even see it
being desirable if I'm being honest), so I'm uncomfortable removing the ability
in a minor release.
Happy to gather a few other opinions though and if the concensus is that the
patch is fine the way it currently is, no problem, not trying to veto this in
any way.
> Don't let user drop (or generally break) tables in system_distributed
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-13813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13813
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata
> Reporter: Sylvain Lebresne
> Assignee: Aleksey Yeschenko
> Fix For: 3.0.x, 3.11.x
>
>
> There is not currently no particular restrictions on schema modifications to
> tables of the {{system_distributed}} keyspace. This does mean you can drop
> those tables, or even alter them in wrong ways like dropping or renaming
> columns. All of which is guaranteed to break stuffs (that is, repair if you
> mess up with on of it's table, or MVs if you mess up with
> {{view_build_status}}).
> I'm pretty sure this was never intended and is an oversight of the condition
> on {{ALTERABLE_SYSTEM_KEYSPACES}} in
> [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397].
> That condition is such that any keyspace not listed in
> {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for
> {{system_distributed}}) has no specific restrictions whatsoever, while given
> the naming it's fair to assume the intention that exactly the opposite.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
