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
