[
https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196920#comment-16196920
]
Sylvain Lebresne commented on CASSANDRA-13813:
----------------------------------------------
bq. But the way ALTER works, we serialise the whole table, including all
params and all columns
Good point, I hadn't though about that part. Sad!
So I guess I would agree in principle about shielding user against clearly
dysfunctional behaviors. The problem is that in practice I know for a fact that
CASSANDRA-12701 has been an issue for some users, where the tables had been
growing way too much, to the point that being able to work-around that by
setting a TTL manually probably override concerns about hypothetical future
changes to defaults not being picked up.
Or to put it another way, none of this is ideal, but I wonder is "repair
history tables regularly grows out of control regularly" isn't a bigger problem
in practice than "future defaults changes to system tables may not be picked
up". Anyway, again, not opposed on the current patch personally, but uneased by
it, so wouldn't mind a few additional opinion to see if it's just me being
difficult (which is possible).
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
