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

Stefan Miklosovic edited comment on CASSANDRA-21046 at 12/4/25 4:28 PM:
------------------------------------------------------------------------

Yes, we should look at KeyspaceParams/TableParams as at "containers" holding 
all "non-essentials". KeyspaceParams are just a vehicle for these parameters to 
be located in. It is different question how we are presenting them to a user - 
whether they are specifying it as "with comment = ..." or they have a dedicated 
CQL syntax for that as introduced in CEP. Having them exposed as "top-level" in 
e.g. TableMetadata is not really necessary. We just need to say that it is 
illegal to use "with comment / security label" when CREATE / ALTER KEYSPACE. 
That is all. Because it was not possible before that CEP, on KEYSPACE, either.

Your original implementation had it right, we just need to ban illegal usage. I 
believe that would also simplify the patch significantly. 


was (Author: smiklosovic):
Yes, we should look at KeyspaceParams/TableParams as at "containers" holding 
all "non-essentials". KeyspaceParams are just a vehicle for these parameters to 
be located in. It is different question how we are presenting them to a user - 
whether they are specifying it as "with comment = ..." or they have a dedicated 
CQL syntax for that as introduced in CEP. Having them exposed as "top-level" in 
e.g. TableMetadata is not really necessary. We just need to say that it is 
illegal to use "with comment / security label" when CREATE / ALTER KEYSPACE. 
That is all. Because it was not possible before that CEP, on KEYSPACE, either.

> Schema annotations escape validation on CREATE and ALTER DDL statements
> -----------------------------------------------------------------------
>
>                 Key: CASSANDRA-21046
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-21046
>             Project: Apache Cassandra
>          Issue Type: Bug
>          Components: Cluster/Schema
>            Reporter: Sam Tunnicliffe
>            Assignee: Jyothsna Konisa
>            Priority: Normal
>             Fix For: 6.x
>
>         Attachments: ci_summary-2.html
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{CREATE KEYSPACE}} & {{CREATE TABLE}} statements silently accept 
> {{security_label}} and {{comment}} as options, but only {{CREATE TABLE ... 
> WITH comment ...}} has any effect. The same applies to {{ALTER KEYSPACE/ALTER 
> TABLE}}.
> {code}
> cqlsh> create KEYSPACE ks1 with replication = {'class': 'SimpleStrategy', 
> 'replication_factor': 1} AND security_label = 'label1' AND comment = 
> 'comment1';
> cqlsh> describe ks1;
> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true  AND fast_path = 
> 'simple';
> {code}
> Supplying an unsupported/unimplemented option to either a {{CREATE}} or 
> {{ALTER}} statement should raise an error like:
> {code}
> cqlsh> alter table ks.t1 with blabla='foooo';
> SyntaxException: Unknown property 'blabla'
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Reply via email to