Hello, everyone. I’ve been reviewing the patch for the constraints framework <https://github.com/apache/cassandra/pull/3562>, and I believe there are several aspects outlined in CEP-42 that warrant reconsideration. I’d like to bring these points up for discussion. *1. New Reserved Keyword*
The patch introduces a new reserved keyword, "CONSTRAINT." Since reserved keywords cannot be used as identifiers unless quoted, this can complicate data definition declarations. We should aim to avoid adding new reserved keywords where possible. Here are a couple of alternatives: 1.1 *Inline Constraint Definition* We could eliminate the keyword "CONSTRAINT." Instead, similar to data masking, constraints could be defined using "CONSTRAINED WITH." For example, in the following code, r_value_range_lower_bound and r_value_range_upper_bound are constraint names, followed immediately by their expressions, with multiple constraints connected using "AND". CREATE TABLE rgb ( name text PRIMARY KEY, r int CONSTRAINED WITH r_value_range_lower_bound CHECK r >= 0 AND r_value_range_upper_bound CHECK r < 256, ... ); 1.2 *Special Symbol* Another option is to use a special symbol to differentiate from identifiers, such as "@CONSTRAINT." However, since there is currently no annotation-like concept in CQL, this might confuse users. CREATE TABLE rgb ( name text PRIMARY KEY, r int, ... @CONSTRAINT r_value_range_lower_bound CHECK r >= 0, @CONSTRAINT r_value_range_upper_bound CHECK r < 256, ... ); *2. Constraint Name* CEP-42 states, "Name of the constraint is optional. If it is not provided, a name is generated for the constraint." However, based on the actual statements defining constraints, I believe names should be *mandatory* for clarity and usability. System-generated names often lack descriptiveness. *3. Cross-Column Constraints* CEP-42 proposes allowing constraints that compare multiple columns. For example, CREATE TABLE keyspace.table ( p1 int, p2 int, ..., CONSTRAINT [name] CHECK (p1 != p2) ); Such constraints can be problematic due to their referential nature. Consider scenarios where column p2 is dropped, or when insert/update operations include only partial values (e.g., only inserting p1). Should the query result in a read (before write), or should it fail due to incomplete values? For simplicity, I propose that, at least for the initial iteration, we exclude support for cross-column constraints. In other words, constraints should only check the values of individual columns. - Yifan On Thu, Sep 19, 2024 at 11:46 AM Patrick McFadin <pmcfa...@gmail.com> wrote: > Thanks for the update. My inbox search failed me :D > > On Thu, Sep 19, 2024 at 11:31 AM Bernardo Botella < > conta...@bernardobotella.com> wrote: > >> Hi Patrick, >> >> Thanks for taking a look at this and keeping the house tidy. >> >> I announced the voting results on a sepparate thread: >> lists.apache.org >> <https://lists.apache.org/thread/v73cwc8p80xx7zpkldjq6w1qrkf2k9h0> >> [image: favicon.ico] >> <https://lists.apache.org/thread/v73cwc8p80xx7zpkldjq6w1qrkf2k9h0> >> <https://lists.apache.org/thread/v73cwc8p80xx7zpkldjq6w1qrkf2k9h0> >> >> As a follow up, this is not stalled, and I’m currently working on a patch >> that will be soon available for review. >> >> Thanks, >> Bernardo >> >> >> On Sep 19, 2024, at 11:20 AM, Patrick McFadin <pmcfa...@gmail.com> wrote: >> >> I'm going to cap this thread. Vote passes with no binding -1s. >> >> On Tue, Jul 2, 2024 at 2:25 PM Jordan West <jorda...@gmail.com> wrote: >> >>> +1 >>> >>> On Tue, Jul 2, 2024 at 12:15 Francisco Guerrero <fran...@apache.org> >>> wrote: >>> >>>> +1 >>>> >>>> On 2024/07/02 18:45:33 Josh McKenzie wrote: >>>> > +1 >>>> > >>>> > On Tue, Jul 2, 2024, at 1:18 PM, Abe Ratnofsky wrote: >>>> > > +1 (nb) >>>> > > >>>> > >> On Jul 2, 2024, at 12:15 PM, Yifan Cai <yc25c...@gmail.com> wrote: >>>> > >> >>>> > >> +1 on CEP-42. >>>> > >> >>>> > >> - Yifan >>>> > >> >>>> > >> On Tue, Jul 2, 2024 at 5:17 AM Jon Haddad <j...@jonhaddad.com> >>>> wrote: >>>> > >>> +1 >>>> > >>> >>>> > >>> On Tue, Jul 2, 2024 at 5:06 AM <shailajako...@icloud.com> wrote: >>>> > >>>> +1 >>>> > >>>> >>>> > >>>> >>>> > >>>>> On Jul 1, 2024, at 8:34 PM, Doug Rohrer <droh...@apple.com> >>>> wrote: >>>> > >>>>> >>>> > >>>>> +1 (nb) - Thanks for all of the suggestions and Bernardo for >>>> wrangling the CEP into shape! >>>> > >>>>> >>>> > >>>>> Doug >>>> > >>>>> >>>> > >>>>>> On Jul 1, 2024, at 3:06 PM, Dinesh Joshi <djo...@apache.org> >>>> wrote: >>>> > >>>>>> >>>> > >>>>>> +1 >>>> > >>>>>> >>>> > >>>>>> On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg < >>>> ar...@weisberg.ws> wrote: >>>> > >>>>>>> __ >>>> > >>>>>>> Hi, >>>> > >>>>>>> >>>> > >>>>>>> I am +1 on CEP-42 with the latest updates to the CEP to >>>> clarify syntax, error messages, constraint naming and generated naming, >>>> alter/drop, describe etc. >>>> > >>>>>>> >>>> > >>>>>>> I think this now tracks very closely to how other SQL >>>> databases define constraints and the syntax is easily extensible to >>>> multi-column and multi-table constraints. >>>> > >>>>>>> >>>> > >>>>>>> Ariel >>>> > >>>>>>> >>>> > >>>>>>> On Mon, Jul 1, 2024, at 9:48 AM, Bernardo Botella wrote: >>>> > >>>>>>>> With all the feedback that came in the discussion thread >>>> after the call for votes, I’d like to extend the period another 72 hours >>>> starting today. >>>> > >>>>>>>> >>>> > >>>>>>>> As before, a vote passes if there are at least 3 binding +1s >>>> and no binding vetoes. >>>> > >>>>>>>> >>>> > >>>>>>>> Thanks, >>>> > >>>>>>>> Bernardo Botella >>>> > >>>>>>>> >>>> > >>>>>>>>> On Jun 24, 2024, at 7:17 AM, Bernardo Botella < >>>> conta...@bernardobotella.com> wrote: >>>> > >>>>>>>>> >>>> > >>>>>>>>> Hi everyone, >>>> > >>>>>>>>> >>>> > >>>>>>>>> I would like to start the voting for CEP-42. >>>> > >>>>>>>>> >>>> > >>>>>>>>> Proposal: >>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-42%3A+Constraints+Framework >>>> > >>>>>>>>> Discussion: >>>> https://lists.apache.org/thread/xc2phmxgsc7t3y9b23079vbflrhyyywj >>>> > >>>>>>>>> >>>> > >>>>>>>>> The vote will be open for 72 hours. A vote passes if there >>>> are at least 3 binding +1s and no binding vetoes. >>>> > >>>>>>>>> >>>> > >>>>>>>>> Thanks, >>>> > >>>>>>>>> Bernardo Botella >>>> > >>>>>>> >>>> >>> >>
favicon.ico
Description: Binary data
