[ 
https://issues.apache.org/jira/browse/CASSANDRA-13812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145097#comment-16145097
 ] 

Aleksey Yeschenko commented on CASSANDRA-13812:
-----------------------------------------------

[~slebresne] The purpose of hardcoding a minimal timestamp value there is to 
avoid mismatches from automated creation, but still allow custom updates (to 
keyspace RF for example). When we do update them in Core, we'd bump the 
timestamp too so that the new default would override the old default, but still 
not affect the overrides by the user - if any. FWIW we've been doing it like 
this since forever, not just CASSANDRA-13441, just not consistently everywhere. 
If I recall correctly, so does DSE. Now, this may or may not work as intended, 
but that was the intention.

As for dropping those tables - no, it should absolutely not be allowed.

bq. But as said above, even outside that particular case, CASSANDRA-13441 means 
(unless I'm missing something) that we cannot ever do any update to a 
system_distributed table (we can add stuffs, but we can't update) and that 
doesn't feel ideal to me.

It's already been the case for tables themselves before 13441, I think. Just 
not for KS metadata. So far we've been lucky to not require any incompatible 
changes.

Overall, I think we should not allow user modifications to our distributed 
system tables (auth, tracing, system_distributed). So long as that is true, we 
can hardcode a timestamp as a generation, and bump it every time we make a 
change. But we should allow altering the keyspace itself by the user - at the 
very least to allow changing RF. I think it's still fine to hard code a 
timestamp there - user's changes will always win, and for keyspaces this is 
what we want - given that the only two params we have on keyspaces are RF and 
durable_writes.

> Missing system keyspace tables are not created
> ----------------------------------------------
>
>                 Key: CASSANDRA-13812
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13812
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Distributed Metadata
>            Reporter: ZhaoYang
>
> Auth/Trace/Distributed Keyspaces or Tables dropped are not created on startup 
> although a log message {{MigrationManager.java:220 - Create new table: 
> TableMetadata...}} appears.
> Steps to reproduce:
> # Start node
> # {{DROP TABLE system_distributed.view_build_status;}}
> # {{DROP TABLE system_distributed.repair_history;}}
> # Stop node
> # Start node
> # Tables are *not* created, but log messages appear
> Cause:
> System's keyspaces or tables are created with timestamp 0 in CASSANDRA-13441



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to