Re: [VOTE] CEP-42: Constraints Framework

After offline discussion (Thanks Yifan and Stefan!), we have decided to drop the support of "table level" constraints at least for this initial implementation, and support defining constraints along with column definitions. This allows us to drop the need of new reserved keywords (no need to def

Re: [VOTE] CEP-42: Constraints Framework

My comment comes from the fact that I find it counter intuitive to have constraints defined at column level that reference other columns. From your example, referencing column b from the column a definition looks off in my head. Besides, validation can become trickier. For instance, when validat

Re: [VOTE] CEP-42: Constraints Framework

Could you give some concrete examples of potential problems when introducing general / cross column constraints? When I have a table where I do not want two columns to contain the same values for a given primary key (and we do not want to deal with a tuple as suggested before), why would this not

Re: [VOTE] CEP-42: Constraints Framework

Hi everyone, Thanks a lot for the constructive discussion! Sorry for coming to it so late in the game, I’ve been out this past week, but I’m back up and running. Really interesting ideas. So, to recap: I do agree that we can keep out from initial implementations the Cross Column Constraints. T

Re: [VOTE] CEP-42: Constraints Framework

We do not have any constraint names so ALTER TABLE ks.table DROP CONSTRAINT a; can not be mistaken for it, but if you insist, this would be better than the alternative: ALTER TABLE ks.table DROP CONSTRAINTS ON column_name; However, that also means that we would have two new reserved words, CONS

Re: [VOTE] CEP-42: Constraints Framework

The identifier "a" in the statement "DROP CONSTRAINT a;" might be mistaken for a constraint name. Revising it to "DROP CONSTRAINTS ON a" more clearly conveys the intent of removing all constraints defined on column "a". However, it requires CONSTRAINTS to be added to the reserved keywords. I would

Re: [VOTE] CEP-42: Constraints Framework

Thanks Yifan, In your example: ALTER TABLE ks.table DROP CONSTRAINTS ON column_name; I think that "ON" is not necessary. If we compare how a column is dropped: ALTER TABLE ks.table DROP a; Then dropping a constraint would be the same, we would just add "CONSTRAINT" in front of a column name:

Re: [VOTE] CEP-42: Constraints Framework

Hi Štefan, The constraint names are to be referenced when altering tables. I like the option you proposed to completely overwrite the column constraints during table alterations, removing the need to declare constraint names. It simplifies the constraint definition. To iterate on the use case of

Re: [VOTE] CEP-42: Constraints Framework

I think you need to name the constraints because you want to do something like this, correct? ALTER TABLE keyspace.table ALTER CONSTRAINT [name] CHECK (condition) But that is only necessary when there are multiple constraints on a column and you want to alter either / both of them. If we had

Re: [VOTE] CEP-42: Constraints Framework

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, ... ); Wh

Re: [VOTE] CEP-42: Constraints Framework

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

Re: [VOTE] CEP-42: Constraints Framework

Hello, everyone. I’ve been reviewing the patch for the constraints framework , 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 pa

Re: [VOTE] CEP-42: Constraints Framework

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

Re: [VOTE] CEP-42: Constraints Framework

Hi Patrick, Thanks for taking a look at this and keeping the house tidy. I announced the voting results on a sepparate thread: 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

Re: [VOTE] CEP-42: Constraints Framework

I'm going to cap this thread. Vote passes with no binding -1s. On Tue, Jul 2, 2024 at 2:25 PM Jordan West wrote: > +1 > > On Tue, Jul 2, 2024 at 12:15 Francisco Guerrero > wrote: > >> +1 >> >> On 2024/07/02 18:45:33 Josh McKenzie wrote: >> > +1 >> > >> > On Tue, Jul 2, 2024, at 1:18 PM, Abe Rat

[RESULT][VOTE] CEP-42: Constraints Framework

The vote passes with 7 binding +1, 3 non binding, and no vetoes. Thanks everyone who was part of the discussion! Bernardo

Re: [VOTE] CEP-42: Constraints Framework

+1 On Tue, Jul 2, 2024 at 12:15 Francisco Guerrero 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 wrote: > > >> > > >> +1 on CEP-42. > > >> > > >>

Re: [VOTE] CEP-42: Constraints Framework

+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 wrote: > >> > >> +1 on CEP-42. > >> > >> - Yifan > >> > >> On Tue, Jul 2, 2024 at 5:17 AM Jon Haddad wrote: > >>> +1 > >>

Re: [VOTE] CEP-42: Constraints Framework

+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 wrote: >> >> +1 on CEP-42. >> >> - Yifan >> >> On Tue, Jul 2, 2024 at 5:17 AM Jon Haddad wrote: >>> +1 >>> >>> On Tue, Jul 2, 2024 at 5:06 AM wrote: +1 > On J

Re: [VOTE] CEP-42: Constraints Framework

+1 (nb) > On Jul 2, 2024, at 12:15 PM, Yifan Cai wrote: > > +1 on CEP-42. > > - Yifan > > On Tue, Jul 2, 2024 at 5:17 AM Jon Haddad > wrote: >> +1 >> >> On Tue, Jul 2, 2024 at 5:06 AM > > wrote: >>> +1 >>> >>> On Jul 1, 2024,

Re: [VOTE] CEP-42: Constraints Framework

+1 on CEP-42. - Yifan On Tue, Jul 2, 2024 at 5:17 AM Jon Haddad wrote: > +1 > > On Tue, Jul 2, 2024 at 5:06 AM wrote: > >> +1 >> >> >> On Jul 1, 2024, at 8:34 PM, Doug Rohrer wrote: >> >> +1 (nb) - Thanks for all of the suggestions and Bernardo for wrangling >> the CEP into shape! >> >> Doug

Re: [VOTE] CEP-42: Constraints Framework

+1 On Tue, Jul 2, 2024 at 5:06 AM wrote: > +1 > > > On Jul 1, 2024, at 8:34 PM, Doug Rohrer 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 wrote: > > +1 > > On Mon, Jul 1, 2024 at 11:

Re: [VOTE] CEP-42: Constraints Framework

+1 > On Jul 1, 2024, at 8:34 PM, Doug Rohrer 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 wrote: >> >> +1 >> >> On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg >

Re: [VOTE] CEP-42: Constraints Framework

+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 wrote: > > +1 > > On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg > wrote: >> Hi, >> >> I am +1 on CEP-42 with the latest updat

Re: [VOTE] CEP-42: Constraints Framework

+1 On Mon, Jul 1, 2024 at 11:58 AM Ariel Weisberg 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 def

Re: [VOTE] CEP-42: Constraints Framework

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 an

Re: [VOTE] CEP-42: Constraints Framework

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

[VOTE] CEP-42: Constraints Framework

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 a