cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
Date Tue, 10 Oct 2017 09:59:01 GMT


Sylvain Lebresne commented on CASSANDRA-13813:

bq. an experience person can still get around this restriction by doing inserts into the schema

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:
>             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|].
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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message