In the CEP document there is another example (altho not explicetly mentioned) adding a constraint to the max value of an int -> `number_of_items int CONSTRAINT number_of_items < 1000`
This basic example can also be used to expand on how to extend this functionality with these two initial constraints (size and value), by composing them to create new data types with proper validation. For example, this could create an ipv4 with built in validation: CREATE TYPE keyspace.cidr_address_ipv4 ( ip_adress inet, subnet_mask int, CONSTRAINT subnet_mask > 0, CONSTRAINT subnet_mask < 32 ) Or a color type: CREATE TYPE keyspace.color ( r int, g int, b int, CONSTRAINT r >= 0, CONSTRAINT r < 255, CONSTRAINT g >= 0, CONSTRAINT g < 255, CONSTRAINT b >= 0, CONSTRAINT b < 255, ) Another types of constraints and functions can be added in the future to provide even more flexibility, but are out of the scope of this CEP. Bernardo > On Jun 4, 2024, at 1:01 PM, Jon Haddad <j...@jonhaddad.com> wrote: > > The idea is interesting. I think it would help to have more concrete > examples. It's a bit sparse at the moment, and I have a hard time getting on > board with new features where the main selling point is Extensibility over > the value they provide on their own. > > I think it would help a lot if we knew what types of constraints, besides the > size check, you were thinking of adding. > > Jon > > On Mon, Jun 3, 2024 at 5:27 PM Bernardo Botella <conta...@bernardobotella.com > <mailto:conta...@bernardobotella.com>> wrote: >> Yes, that is correct. This particular behavior will need CEP-24 in order to >> work reliably. But, if my understanding is correct, that statement holds >> true for the entirety of Guardrails, and not only for this particular >> feature. >> >>> On Jun 3, 2024, at 3:54 PM, Miklosovic, Stefan >>> <stefan.mikloso...@netapp.com <mailto:stefan.mikloso...@netapp.com>> wrote: >>> >>> 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 >>> <mailto:conta...@bernardobotella.com>> >>> Date: Tuesday, 4 June 2024 at 00:31 >>> To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org> >>> <dev@cassandra.apache.org <mailto:dev@cassandra.apache.org>> >>> Cc: Miklosovic, Stefan <stefan.mikloso...@netapp.com >>> <mailto:stefan.mikloso...@netapp.com>> >>> Subject: Re: [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 >>> >>> >>> >>> 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 <mailto: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 >>
