That would work reliably in case there is no way how to misconfigure guardrails in the cluster. What if you set a guardrail on one node but you don’t set it (or set it differently) on the other? If it is configured differently and you want to check the guardrails if constraints do not violate them, then your query might fail or not based on what node is hit.
I guess that guardrails would need to start to be transactional to be sure this is avoided and guardrails are indeed same everywhere (CEP-24 thread sent recently here in ML). From: Bernardo Botella <conta...@bernardobotella.com> Date: Tuesday, 4 June 2024 at 00:31 To: dev@cassandra.apache.org <dev@cassandra.apache.org> Cc: Miklosovic, Stefan <stefan.mikloso...@netapp.com> Subject: Re: [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 Basically, I am trying to protect the limits set by the operator against misconfigured schemas from the customers. I see the guardrails as a safety limit added by the operator, setting the limits within the customers owning the actual schema (and their constraints) can operate. With that vision, if a customer tries to “ignore” the actual limits set by the operator by adding more relaxed constraints, it gets a nice message saying that “that is not allowed for the cluster, please contact your admin". On Jun 3, 2024, at 2:51 PM, Miklosovic, Stefan via dev <dev@cassandra.apache.org> wrote: 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<mailto:conta...@bernardobotella.com>> Date: Friday, 31 May 2024 at 23:24 To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org> <dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>> Subject: [DISCUSS] CEP-42: Constraints Framework You don't often get email from conta...@bernardobotella.com<mailto: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
