You wrote in the CEP: As we mentioned in the motivation section, we currently have some guardrails for columns size in place which can be extended for other data types. Those guardrails will take preference over the defined constraints in the schema, and a SCHEMA ALTER adding constraints that break the limits defined by the guardrails framework will fail. If the guardrails themselves are modified, operator should get a warning mentioning that there are schemas with offending constraints.
I think that this should be other way around. Guardrails should kick in when there are no constraints and they would be overridden by table schema. That way, there is always a “default” in terms of guardrails (which one can turn off on demand / change) but you can override it by table alternation. Basically, what is in schema should win regardless of how guardrails are configured. They don’t matter when a constraint is explicitly specified in a schema. It should take the defaults in guardrails if there are any and no constraint is specified on schema level. What is your motivation to do it like you suggested? From: Bernardo Botella <conta...@bernardobotella.com> Date: Friday, 31 May 2024 at 23:24 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: [DISCUSS] CEP-42: Constraints Framework You don't often get email from conta...@bernardobotella.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments Hello everyone, I am proposing this CEP: CEP-42: Constraints Framework - CASSANDRA - Apache Software Foundation<https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework> cwiki.apache.org<https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework> [favicon.ico]<https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework> And I’m looking for feedback from the community. Thanks a lot! Bernardo
