Thanks for the clarification Jon. I will update the CEP being specific with the two specific Constraint types I will be adding, which are size and value (the ones shown in the example).
And, just to clarify, the mention to extensibility just aims to state that the feature should be built in a way that allow more constraints being added. > On Jun 5, 2024, at 9:24 PM, Jon Haddad <j...@jonhaddad.com> wrote: > > I think there's some promising ideas here, but the CEP needs to be developed > a bit more. > > > 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. > > > For the third point, I didn’t want to be prescriptive on what those > > validations should be, but the fact that the proposal is extensible to > > those potential use cases is something concrete that, in my opinion, comes > > as a benefit of the actual proposal. I’d be happy to develop a bit more the > > main example used of sizeOf if it helps alleviate your concerns on this > > point. > > I disagree, quite strongly, with this. While I appreciate extensibility, I > think having a variety of actual constraints that ship with the feature means > it needs to be built to satisfy real world use cases. Without going through > this process, it feels a bit too much like triggers, UDAs and UDFs - > incomplete, and too much left to the end user. > > To me, punting on thinking through constraints kicks the most important can > down the road. > > Jon > > > On Tue, Jun 4, 2024 at 5:37 PM Bernardo Botella <conta...@bernardobotella.com > <mailto:conta...@bernardobotella.com>> wrote: >> 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 >>> <mailto: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 >>>> >>
