[
https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198456#comment-16198456
]
Sylvain Lebresne commented on CASSANDRA-13813:
----------------------------------------------
bq. an experience person can still get around this restriction by doing inserts
into the schema tables
I also just realized that doing so actually avoids the issue we currently have
with {{ALTER}} that it rewrites all columns, so it makes it a somewhat better
work-around (of course, still a work-around and that don't dispense us for
fixing all this more cleanly). My only bother is that while I haven't actually
tried it recently, last time I did try updating the schema tables manually, it
was annoying because the changes were not automatically picked-up and in fact
tended to be overridden, so I had to force a reload in weird ways (altering
some other unrelated table in the keyspace, which here would actually be an
issue). So it would be nice if we added a JMX call to force reload schema
tables from disk to make this easier (should be easy). If we do, I'm warming up
to the idea of considering this is the only really safe work-around until we
find a better way to deal with all thise.
bq. if we can't provide a data model for our tables that works for all
scenarios then we need to allow operators to make changes.
I'm not sure what you are trying to mean by that. If it's a reference to
CASSANDRA-12701, then what makes that change problematic is the very same
reason why leaving {{ALTER}} working here is problematic. So feel free to
suggest a concrete solution to those problems if you have one, but otherwise,
I'm not sure how this statement helps make a decision on this issue.
bq. I've had quite a few occasions where modifying "system" tables was
necessary, and I'm sure more tables will be introduced that don't work in all
scenarios in the future.
First, it would be nice if you could be a bit more concrete on those time where
it was "necessary": which tables, what modification and why what it necessary?
We're trying to find the best course of action for a very concrete problem and
we are all experienced C* developers: let's be specific.
Second, I'm not sure how to re-conciliate that sentence as a whole to the
concrete problem at end. Let's remind that we do _already_ refuse {{ALTER}} on
most system tables, and this ticket is not about discussing whether we should
allow {{ALTER}} on system tables _in general_. If you want to discuss that, I'm
good with it (outside of the fact that we will have to solve the technical
gotcha mentioned above) and your arguments seem to really be applied to such
change, but please open a separate ticket and let's not divert that one.
> 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
