Got it. Thanks for the clarification Jon. Then, in terms of syntax, I think we can discard the option 2.
In terms of GUARDRAIL vs CONSTRAINT concept you bring up, I guess here we have pros and cons for both sides. It is true that there is an existing concept of GUARDRAIL on Cassandra, and that reusing it comes with benefits. But, in my opinion, there are two main advantages to use the CONSTRAINT name for the feature: - It keeps consistency with concepts from other databases (this may be a minor, but I really think there is benefit for those coming from other databases, and may help them understand what this actually is) - Having it presented as a different concept help illustrate how those two features are different. Following the example provided by Doug, we can have clear separation on those two levels of restrictions to a write. > On Jun 24, 2024, at 9:46 PM, Jon Haddad <j...@jonhaddad.com> wrote: > > I think my suggestion was unclear. I was referring to the name guardrail, > using the same infra as guardrails, rather than a separate concept. Not > applying it like we do table options. > > > > On Tue, Jun 25, 2024 at 12:44 AM Bernardo Botella > <conta...@bernardobotella.com <mailto:conta...@bernardobotella.com>> wrote: >> Hi Ariel and Jon, >> >> Let me address your question first. Yes, AND is supported in the proposal. >> Below you can find some examples of different constraints applied to the >> same column. >> >> As per the LENGTH name instead of sizeOf as in the proposal, I am also not >> opposed to it if it is more consistent with terminology in the databases >> universe. >> >> So, to recap, there seems to be general agreement on the usefulness of the >> Constraints Framework. >> Now, from the feedback that has arrived after the voting has been called, I >> see there are three different proposals for syntax: >> >> 1.- >> The syntax currently described in the CEP. Example: >> CREATE TYPE keyspace.cidr_address_ipv4 ( >> ip_adress inet, >> subnet_mask int, >> CONSTRAINT subnet_mask > 0, >> CONSTRAINT subnet_mask < 32 >> ) >> >> 2.- >> As Jon suggested, leaving this definitions to more specific Guardrails at >> table level. Example, something like: >> column_min_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 0 >> column_max_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 32 >> >> 3.- >> As Ariel suggested, having the CHECK keyword added to align consistency with >> SQL. Example: >> CREATE TYPE keyspace.cidr_address_ipv4 ( >> ip_adress inet, >> subnet_mask int, >> CONSTRAINT CHECK subnet_mask > 0, >> CONSTRAINT CHECK subnet_mask < 32 >> ) >> >> For the guardrails vs cql syntax, I think that keeping the conceptual >> separation that has been explored in this thread, and perfectly recapped by >> Doug, is closer to what we are trying to achieve with this framework. In my >> opinion, having them in the CQL schema definition provides those application >> level constraints that Doug mentions in an more accesible way than having to >> configure such specific guardrais. >> >> For the addition of the CHECK keyword, I'm definitely not opposed to it if >> it helps Cassandra users coming from other databases understand concepts >> that were already familiar to them. >> >> I hope this helps move the conversation forward, >> Bernardo >> >> >> >>> On Jun 24, 2024, at 12:17 PM, Ariel Weisberg <ar...@weisberg.ws >>> <mailto:ar...@weisberg.ws>> wrote: >>> >>> Hi, >>> >>> I see a vote for this has been called. I should have provided more prompt >>> feedback sooner. >>> >>> I am a strong +1 on adding column level constraints being a good thing to >>> add. I'm not too concerned about row/partition/table level constraints, but >>> I would like to change the syntax before I would be +1 on this CEP. >>> >>> It would be good to align the syntax as closely as possible to our existing >>> syntax, and if not that then MySQL/Postgres. For example it looks like we >>> don't have a string length function so maybe add `LENGTH` (consistent with >>> MySQL/Postgres) to also use with column level constraints. >>> >>> It looks like there are generally two forms of constraint syntax, one is >>> expressed as part of the column definition, and the other is a named or >>> anonymous constraint on the table. >>> https://www.w3schools.com/sql/sql_check.asp >>> >>> Can we align with having these column level ones as `CHECK` constraints >>> like in SQL, and `CONSTRAINT [constraint_name] CHECK` would be used if >>> creating a named or multi-column constraint? >>> >>> Will column level check constraints support `AND` so that you can specify >>> multiple constraints on the column? I am not sure if that is supported in >>> other databases, but it would be good to align on that as well. >>> >>> RE some implementation things to keep in mind: >>> >>> If TCM is in use and the constraints are defined in the schema data >>> structure this should work fine with Accord because all coordinators >>> (regular, recovery) will deterministically agree on the constraints being >>> enforced BUT... this also has to map to how/when constraints are enforced. >>> >>> Both Accord and Paxos work best when the constraints are enforced when the >>> final mutation to be applied is created and not later when it is being >>> applied to the CFS. This also reduces duplication of enforcement checking >>> work to just the coordinator for the write. >>> >>> Ariel >>> >>> On Fri, May 31, 2024, at 5:23 PM, Bernardo Botella wrote: >>>> 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 >>
