1.1. CONSTRAINED WITH is good for me 1.2 I prefer 1.1. approach.
2. I am for explicit names over generated ones. I think that the only names which are generated are names for indexes when not specified. 3. I am OK with the exclusion. This is an interesting problem. If somebody wants these two to be constrained and checked then I guess the solution would be to have them both in a tuple instead of in two different columns. So we do not need to support this cross-columns feature. However, I am not sure how we would go around checking tuples. Is that covered? We would need to find a way how to reference that create table a_table (int id, a_tuple tuple<int, int>, CONSTRAINT a_tuple_constraint CHECK (a_tuple.1 != a_tuple.2) or something similar. BTW there is nothing about tuples in that CEP yet. On Fri, Oct 25, 2024 at 12:21 AM Yifan Cai <yc25c...@gmail.com> wrote: > 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
