Thinking about this more .. 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, ... );
What about this: CREATE TABLE rgb ( name text PRIMARY KEY, r int CONSTRAINED WITH r >= 0 AND r < 256, ... ); Why do we need to have names and CHECK after all? I am sorry if this was already answered and I am glad to be educated in this area. Regards On Fri, Oct 25, 2024 at 5:13 PM Štefan Miklošovič <smikloso...@apache.org> wrote: > 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
