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

Michael Semb Wever edited comment on CASSANDRA-19556 at 5/20/24 5:12 PM:
-------------------------------------------------------------------------

[~samt], I'm interested in hearing where you're at on this… 

This issue is not a 5.0-rc blocker, but if it is ready to be committed, and 
there's an important enough reason to commit it for the sake of upgrading to 
tcm, then that's our argument to present.  It's also worth pointing out that 
trunk is still for now 5.1, so upgrades from 4.0 and 4.1 to tcm would still be 
possible too.  My general sentiment remains we're way past the gate for this 
patch, our normal deprecation cycle suffices and we shouldn't be afraid of 
adding what feels like duplication… 

[~smiklosovic], it's still time-consuming having to scan the comments every 
time to figure out which patch is "Ready to Commit".  Can we please keep the 
links section up to date.  This makes the ticket not "super simple", which 
would help put at ease any new reviewers… 


was (Author: michaelsembwever):
[~samt], I'm interested in hearing where you're at on this… 

This issue is not a 5.0-rc blocker, but if it is ready to be committed, and 
there's an important enough reason to commit it for the sake of upgrading to 
tcm, then that's our argument to present.  It's also worth pointing out that 
trunk is still for now 5.1, so upgrades from 4.0 and 4.1 to tcm would still be 
possible too.  My general sentiment remains we're way past the gate for this, 
our normal deprecation suffices and we shouldn't be afraid of adding what feels 
like duplication… 

[~smiklosovic], it's still time-consuming having to scan the comments every 
time to figure out which patch is "Ready to Commit".  Can we please keep the 
links section up to date.  This makes the ticket not "super simple", which 
would help put at ease any new reviewers… 

> Add guardrail to block DDL/DCL queries and replace alter_table_enabled 
> guardrail
> --------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-19556
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Feature/Guardrails
>            Reporter: Yuqi Yan
>            Assignee: Yuqi Yan
>            Priority: Normal
>             Fix For: 5.0-rc, 5.x
>
>          Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created 
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op 
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The 
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if 
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. 
> at startup, which is no-op but will be blocked by this guardrail and failed 
> to start.
>  
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>  



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

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to