Re: [VOTE] Simplifying our release versioning process

+1 > On Apr 22, 2025, at 7:20 PM, Joseph Lynch wrote: > > I'm unclear if Josh/Ekaterina/Benedict's statements are part of the vote > amending our project governance. If consensus is required for breaking > changes with a strong preference for not breaking I am +1, but the original > text of J

Re: Project hygiene on old PRs

d "fighting" this and I just run a >>>> script every few weeks. Funny that people don't forget to create a PR when >>>> trying to make a change but as soon as it is delivered the respective PR >>>> is "memory holed". A PR does not

Re: Constraint's "not null" alignment with transactions and their simplification

Now this is becoming a really interesting discussion. Thanks everyone for pitching in! Here is my take on some of the proposed changes: We are talking about treating some constraints (NOT_NULL, JSON) as special cases by omitting the CHECK keyword (not reserved as per current implementation). N

Re: Project hygiene on old PRs

Just for reference, I ran a script I wrote using Stefan’s as inspiration, and there are 413 PRs without any activity for the past 6 months. Bernardo > On Apr 14, 2025, at 6:39 AM, Štefan Miklošovič wrote: > > > > On Mon, Apr 14, 2025 at 3:22 PM Josh McKenzie > w

Re: Project hygiene on old PRs

he status quo; the information is all still >> available in github but the status of the PR's will communicate different >> things. >> >> On Thu, Apr 10, 2025, at 7:14 PM, Bernardo Botella wrote: >>> Hi everyone! >>> >>> First of all, this ma

Re: Constraint's "not null" alignment with transactions and their simplification

Benedict: An alternative for that, keeping the CHECK word, would be to change the constraint name to IS_JSON. CHECK IS_JSON would read as you intend without the need to jump to REQUIRE. I think that’s true for the rest of provided constraints as well. Bernardo > On Apr 11, 2025, at 6:02 AM,

Project hygiene on old PRs

Hi everyone! First of all, this may have come out before, and I understand it is really hard to keep a tidy house with so many different collaborations. But, I can't help the feeling that coming to the main Apache Cassandra repository and seeing more than 600 open PRs, some of them without acti

Re: [DISCUSS] 5.1 should be 6.0

+1 on 6.0 > On Apr 10, 2025, at 1:07 PM, Josh McKenzie wrote: > > Let's keep this thread to just +1's on 6.0; I'll see about a proper isolated > [DISCUSS] thread for my proposal above hopefully tomorrow, schedule > permitting. > > On Thu, Apr 10, 2025, at 3:46 PM, Jeremiah Jordan wrote: >> +1

Re: [VOTE][IP CLEARANCE] Spark-Cassandra-Connector

+1 (nb) > On Mar 18, 2025, at 10:52 AM, Yifan Cai wrote: > > +1 (nb) > > From: Jeremiah Jordan > Sent: Tuesday, March 18, 2025 10:32:14 AM > To: dev@cassandra.apache.org > Cc: gene...@incubator.apache.org > Subject: Re: [VOTE][IP CLEARANCE] Spark-Cassandra-Connector > > +1 > > On Mar 18,

Re: [RELEASE] Apache Cassandra Sidecar 0.1.0 released

This is a huge milestone! It’s incredible to see this release happening. Congrats to everyone involved! > On Mar 7, 2025, at 9:48 AM, Francisco Guerrero wrote: > > The Cassandra team is pleased to announce the release of Apache Sidecar > Cassandra version 0.1.0. > > > Downloads of source and

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

Congratulations!! On Tue, Mar 4, 2025 at 22:17 Berenguer Blasi wrote: > Congrats Ekaterina! > On 5/3/25 2:03, Jasonstack Zhao Yang wrote: > > Congratulations Ekaterina! > > On Wed, 5 Mar 2025 at 08:18, Josh McKenzie wrote: > >> Welcome Ekaterina! \o/ >> >> On Tue, Mar 4, 2025, at 7:07 PM, Fran

Re: Welcome Aaron Ploetz as Cassandra Committer

That’s awesome!! Congratulations Aaron!! Long overdue for sure! On Mon, Mar 3, 2025 at 16:25 Patrick McFadin wrote: > The Apache Cassandra PMC is very happy to announce that Aaron Ploetz has > accepted the invitation to become a committer! > > Aaron has been tireless in his mission to help eve

Re: [VOTE] Release Apache Sidecar Cassandra 0.1.0

+1 (nb) Awesome milestone On Fri, Feb 28, 2025 at 11:06 Josh McKenzie wrote: > +1 - great work everyone! > > On Fri, Feb 28, 2025, at 1:58 PM, Dinesh Joshi wrote: > > +1, thanks to everyone who worked towards this milestone. > > On Fri, Feb 28, 2025 at 10:47 AM Doug Rohrer wrote: > > +1 (nb) >

Re: Welcome Caleb Rackliffe to the PMC

So many good news today! Congratulations Caleb! > On Feb 20, 2025, at 4:07 PM, Ekaterina Dimitrova > wrote: > > That’s awesome addition! Well done! Thanks for everything, Caleb!! Congrats!!! > > On Thu, 20 Feb 2025 at 18:55, Jeremiah Jordan > wrote: >> Congrats C

[DISCUSS] Virtualise system_schema (CASSANDRA-19129)

Hi everyone! As part of Jira ticket (CASSANDRA-20331) involving creating a new system table to improve Cosntraints support on the driver, I have been pointed to this other Jira (CASSANDRA-19129). It makes perfect sense for us to move to virtual tables, and avoid increasing the snowball of table

Re: New committers: Maxwell Guo and Dmitry Konstantinov

Nice!! Congratulations Maxwell and Dmitry!! Well deserved milestone!! And great for the community! > On Feb 20, 2025, at 9:47 AM, Štefan Miklošovič wrote: > > The Project Management Committee (PMC) for Apache Cassandra > has invited Maxwell Guo and Dmitry Konstantinov to become committers and

Re: Welcome Jeremiah Jordan to the PMC

Congrats! > El feb 16, 2025, a las 9:08 a. m., Aaron escribió: > > Congratulations, JD! > > On Sat, Feb 15, 2025 at 7:05 AM Jasonstack Zhao Yang > mailto:jasonstack.z...@gmail.com>> wrote: >> Congrats! >> >> On Sat, 15 Feb 2025 at 20:25, Maxim Muzafarov > > wrote: >>

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

he reason is: NOT_NULL can easily make users think that it is a related > function of MYSQL, but in fact we are different. > Changing a different name may avoid users' preconceived feelings. > > Dinesh Joshi mailto:djo...@apache.org>> 于2025年2月11日周二 > 01:55写道： >> On M

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

strict >> version. >> How about we just drop the LOOSE one and call the STRICT one “NOT_NULL”? >> >> - Yifan >> From: Bernardo Botella > <mailto:conta...@bernardobotella.com>> >> Sent: Monday, February 10, 2025 8:44:13 AM >> To: dev@cassan

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

ertently write a NULL value for a column specified as NOT_NULL. >> > > Yes. I see it the same way. > >> On Mon, Feb 10, 2025 at 6:50 AM Bernardo Botella >> mailto:conta...@bernardobotella.com>> wrote: >>> Hi everyone, >>> >>> Stef

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

” or some > other additional keywords to make clear we aren’t checking the constraint > applies to existing data. > > >> On 10 Feb 2025, at 15:10, Bernardo Botella >> wrote: >> >> Hi. These was a topic we discussed during the ML thread: >> http

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

table, not to the update. NOT NULL should imply a value is always specified. > > How are you handling this for tables that already exist? Can we alter table > to add constraints, and if so what are the semantics? > >> On 10 Feb 2025, at 14:50, Bernardo Botella >>

[DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

Hi everyone, Stefan Miklosovic and I have been working on a NOT_NULL (https://github.com/apache/cassandra/pull/3867) constraint to be added to the constraints tool belt, and a really interesting conversation came up. First, as a problem statement, let's consider this: -

Re: [DISCUSS] Fine grained max size guardails

geable. Some modifiers on size > will be required in order to distinguish. > > - Yifan > > On Sat, Feb 8, 2025 at 8:50 PM Bernardo Botella <mailto:conta...@bernardobotella.com>> wrote: >> Yifan: how is the SIZE constraint from the LENGTH constraint? -> I think you &

Re: [DISCUSS] Fine grained max size guardails

vant guardrail, as long as the write failure indicates whether the > size violates the guardrail or column constraint, which should be propagated > to clients for transparency. > > Btw, how is the SIZE constraint from the LENGTH constraint? > > - Yifan > > On Sat,

Re: [DISCUSS] Fine grained max size guardails

1MiB then a constraint in the schema cannot go beyond this max > size limit. This allows the operator to define reasonable limits while > allowing the developer control over their application’s limits. > > On Sat, Feb 8, 2025 at 12:03 PM Bernardo Botella > mailto:conta...

[DISCUSS] Fine grained max size guardails

Hi everyone, After Constraints framework was merged in, I would like to come back to the discussion Jordan brought up in this Jira: https://issues.apache.org/jira/browse/CASSANDRA-19677 For context, that Jira ticket (and PR) is adding a bunch of more fine grained size thresholds for column type

Re: [VOTE] CEP-45: Mutation Tracking

+1 (nb) > On Feb 4, 2025, at 12:34 PM, Dinesh Joshi wrote: > > +1 > > On Mon, Feb 3, 2025 at 10:35 AM Blake Eggleston > wrote: >> Hi dev@, >> >> I’d like to start the voting for CEP-45: Mutation Tracking >> >> Proposal: >> https://cwiki.apache.org/confluence/dis

Re: February 2025 project status update

Thanks a lot Josh for those Jira filters!! I think they are going to be really useful to avoid having hanging and stale tickets, reducing contributors frustration for not getting the deserved attention. It is great to see community activity growing! Bernardo > On Feb 3, 2025, at 9:35 AM, Josh

Re: 【DISCUSS】What is the current status of triggers in Cassandra ?

+1 on skipping triggers if we can’t make sure that it will work in every scenario. The experience of copying a table and having a broken result is definitely something to avoid. Kind regards, Bernardo > On Jan 31, 2025, at 10:49 AM, Brandon Williams wrote: > > I agree, and triggers are an ex

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

Love the suggestion of marking the hidden/advanced configuration properties with annotations. Leaving a “configuration” property out of the main configuration file should be deliberate and well thought and argued. I highly doubt we have 112 “advanced” properties that really need to be hidden to

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

Love the suggestion of marking the hidden/advanced configuration properties with annotations. Leaving a “configuration” property out of the main configuration file should be deliberate and well thought and argued. I highly doubt we have 112 “advanced” properties that really need to be hidden to

Re: Patrick McFadin joins the PMC

Nice! Congrats Patrick! > On Jan 22, 2025, at 8:05 AM, Jordan West wrote: > > The PMC's members are pleased to announce that Patrick McFadin has accepted > an invitation to become a PMC member. > > Thanks a lot, Patrick, for everything you have done for the project all these > years. > > C

Re: [DISCUSS] Review Guide for the project

Well, as a growing member on this community, I definitely see benefit on such a review style guide. I’d also be more than happy to participate on its creation with my “fresh eyes reviewer” hat, as someone that hasn’t been reviewing PR for as long as other members of the community. Having said t

Re: Checkstyle as style contract for Cassandra

t; >>> >>>>>> >>> Perhaps a “Review Guide” is what we need to make sure we keep review >>>>>> >>> primarily focused on the core contribution, and to help avoid folk >>>>>> >>> getting bogged down in style s

Checkstyle as style contract for Cassandra

Hi everyone! I wanted to raise a question about code style for the project. I've been receiving some feedback on PRs about the need to: - Have curly braces start on a new line - Remove curly braces if the condition or loop has only one expression Taking a look at the official Code Style stated i

Re: Capabilities

+1 to the positive sentiment of such a feature. Huge benefit towards reducing risks. > On Dec 19, 2024, at 8:31 AM, Patrick McFadin wrote: > > Thanks for bringing this back, Jordan. I had completely forgotten > about Riak's Capabilities support. That was a fan favorite for > operators, along wi

Re: Joining Slack as a multi channel guest

Hi Soheil, I think Brandon refers to this Jira project https://issues.apache.org/jira/projects/INFRA/ Regards, Bernardo > On Dec 16, 2024, at 10:04 AM, Soheil Rahsaz wrote: > > Thank you for your quick response. > How do I contact INFRA? > Should I Use Apache's Jira and put `INFRA` as the pro

Re: Planet Cassandra meetup organizer opportunity

Hi Melissa, I’ll be happy to jump in to keep this going. Let’s sync about this when you have a chance. Regards, Bernardo > On Dec 6, 2024, at 10:17 AM, Melissa Logan wrote: > > Hi folks: > > My team and I created and managed the Planet Cassandra Meetup - a virtual > monthly meetup to share

Re: [VOTE] CEP-42: Constraints Framework

the created constraints on a column ALTER TABLE keyspace.color ALTER r DROP CHECK; // Alter the constraints on a column ALTER TYPE keyspace.color ALTER r CHECK r >= 10 AND r < 20; Thanks everyone! Bernardo > On Nov 4, 2024, at 1:15 PM, Bernardo Botella > wrote: > > My com

Re: [VOTE] CEP-43: Apache Cassandra CREATE TABLE LIKE

n >> <https://lists.apache.org/list?dev@cassandra.apache.org:lte=1M:create%20table%20like> >> >> As per the CEP process documentation, this vote will be open for 72 hours >> (longer if needed). >> >> Bernardo Botella > <mailto:conta...@bernardobotella.com&g

Re: Backporting CASSANDRA-17812 to 4.x

+1 on back porting it > On Nov 5, 2024, at 8:51 AM, Štefan Miklošovič wrote: > > Backporting in such a way that all auth requests will still go to the same > request executor as before is OK for me. > > On Tue, Nov 5, 2024 at 3:32 PM J. D. Jordan > wrote: >>

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 (non binding) > On Nov 5, 2024, at 1:28 PM, Jaydeep Chovatia > wrote: > > Hi Everyone, > > I would like to start the voting for CEP-37 as all the feedback in the > discussion thread seems to be addressed. > > Proposal: CEP-37 Repair Scheduling Inside Cassandra >

Re: [VOTE] CEP-42: Constraints Framework

nal representation to contain > constraints which are named "ks_tb_a" and "ks_tb_b", it is just I do not need > to use it in CQL every single time I am going to interact with that. So, keep > the names if you want and if you think that multicolumn constraints > a

Re: [VOTE] CEP-42: Constraints Framework

sking, 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 >>>>>>&g

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

e. Having the SELECT permission on >>>>>>>>>>>>>>>>>> the original table is a requirement for CREATE TABLE LIKE. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>&g

Re: [VOTE] CEP-44: Kafka integration for Cassandra CDC using Sidecar

+1 nb > On Oct 17, 2024, at 5:52 PM, Josh McKenzie wrote: > > +1 > > On Thu, Oct 17, 2024, at 2:51 PM, Yifan Cai wrote: >> +1 nb >> >> >> From: Brandon Williams >> Sent: Thursday, October 17, 2024 11:47:13 AM >> To: dev@cassandra.apache.org >> Subject: Re: [VOTE] CEP-44: Kafka integration f

Re: [DISCUSS] Modeling JIRA fix version for subprojects

+1 to CASSANALYTICS > On Oct 17, 2024, at 1:48 PM, Yifan Cai wrote: > > yep. CASSANALYTICS sounds good to me. +1 > > On Thu, Oct 17, 2024 at 1:45 PM Francisco Guerrero > wrote: >> > Can we include Cassandra Analytics to the infra ticket? I am looking >> > forward to

Re: [VOTE] CEP-43: Apache Cassandra CREATE TABLE LIKE

Fair point. I will move my feedback there. > On Oct 15, 2024, at 4:19 PM, Yifan Cai wrote: > > For further discussions, should we use the discussion thread? This thread is > for voting. > > - Yifan > > On Tue, Oct 15, 2024 at 3:31 PM Bernardo Botella > mailto:c

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

t;>> name) must be different from the original tables' ,otherwise names >>>>>> would clash . >>>>>> >>>>>> So regarding the above problem, one idea I have is that for newly >>>>>> created types, indexes and views under d

Re: [VOTE] CEP-43: Apache Cassandra CREATE TABLE LIKE

Hi Guo, Do you think it would make sense to add a fourth keyword to add after the WITH for Constraints? (See CEP-42) Copying a table without the defined constraints may be useful. Bernardo > On Oct 9, 2024, at 9:32 PM, guo Maxwell wrote: > > ok, I think the time can be two weeks . > > Loo

Re: [DISCUSS] CEP-44: Kafka integration for Cassandra CDC using Sidecar

wrote: >>>> Patrick, could you please elaborate? The Sidecar has been a thing for a >>>> while now. >>>> >>>> On Mon, Sep 30, 2024 at 7:51 AM Patrick McFadin >>> <mailto:pmcfa...@gmail.com>> wrote: >>>> I made the mi

Re: [DISCUSS] Donating easy-cass-stress to the project

Just found out about this thread. I do agree, after seeing Jon and Jordan’s talk on this tool, it would be great to have it under the project umbrella. Like Alexander, I have also some ideas on workflows to contribute, and would love to help maintain it. Bernardo > On Oct 8, 2024, at 1:51 PM,

Re: [DISCUSS] CEP-44: Kafka integration for Cassandra CDC using Sidecar

-44%3A+Kafka+integration+for+Cassandra+CDC+using+Sidecar >>>>> >>>>> We would like to propose this CEP for adoption by the community. >>>>> >>>>> CDC is a common technique in databases but right now there is no >>>>> out-of-the-box solution to do this easily and at scale with Cassandra. >>>>> Our proposal is to build a fully-fledged solution into the Apache >>>>> Cassandra Sidecar. This comes with a number of benefits: >>>>> - Sidecar is an official part of the existing Cassandra eco-system. >>>>> - Sidecar runs co-located with Cassandra instances and so scales with the >>>>> cluster size. >>>>> - Sidecar can access the underlying Cassandra database to store CDC >>>>> configuration and the CDC state in a special table. >>>>> - Running in the Sidecar does not require additional external resources >>>>> to run. >>>>> >>>>> The core CDC module we anticipate will be pluggable and re-usable, it is >>>>> available for review here: >>>>> https://github.com/apache/cassandra-analytics/pull/87. The remaining >>>>> Sidecar code will follow. >>>>> >>>>> As a reminder, please keep the discussion here on the dev list vs. in the >>>>> wiki, as we’ve found it easier to manage via email. >>>>> >>>>> Sincerely, >>>>> James Berragan >>>>> Bernardo Botella Corbi >>>>> Yifan Cai >>>>> Jyothsna Konisa

Re: [VOTE] CEP-42: Constraints Framework

t;>> >>> > >>>>> Doug >>> > >>>>> >>> > >>>>>> On Jul 1, 2024, at 3:06 PM, Dinesh Joshi >> > >>>>>> <mailto:djo...@apache.org>> wrote: >>> > >>>>>

Re: Welcome Chris Bannister, James Hartig, Jackson Flemming and João Reis, as cassandra-gocql-driver committers

It is great to see the project growing like this. Congratulations!! > On Sep 12, 2024, at 6:27 AM, Tolbert, Andy wrote: > > Congratulations everyone! 🎉 > > On Thu, Sep 12, 2024 at 6:41 AM Mick Semb Wever > wrote: >> The PMC's members are pleased to announce that Chris B

Re: [VOTE] Release test-api 0.0.17

+1 nb > On Sep 10, 2024, at 7:34 AM, Doug Rohrer wrote: > > Proposing the test build of in-jvm dtest API 0.0.17 for release > > Repository: > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git > > Candidate SHA: > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/85

Re: Welcome Jordan West and Stefan Miklosovic as Cassandra PMC members!

Congrats you both! > On Aug 30, 2024, at 1:32 PM, Melissa Logan wrote: > > Great news - congrats Jordan and Stefan! > > On Fri, Aug 30, 2024 at 1:31 PM Sumanth Pasupuleti > mailto:sumanth.pasupuleti...@gmail.com>> > wrote: >> Congratulations Jordan and Stefan!!! >> >> On Fri, Aug 30, 2024 at

Re: Welcome Doug Rohrer as Cassandra Committer

Congratulations Doug! > On Aug 23, 2024, at 1:20 PM, Yifan Cai wrote: > > Congrats Doug! > From: Jordan West > Sent: Friday, August 23, 2024 1:19:04 PM > To: dev@cassandra.apache.org > Subject: Re: Welcome Doug Rohrer as Cassandra Committer > > Awesome! Congratulations Doug! > > On Fri, Au

Re: [DISCUSS] Introduce CREATE TABLE LIKE grammer

Definitely a nice addition to CQL. Looking for inspiration at how Postgres and Mysql do that may also help with the final design (I like the WITH proposed by Stefan, but I would definitely take a look at the INCLUDING keyword proposed by Postgres). https://www.postgresql.org/docs/current/sql-cre

[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-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

+1 (nb) > On Jul 2, 2024, at 2:15 PM, Jordan West wrote: > > +1 > > On Fri, Jun 28, 2024 at 05:56 > wrote: >> +1 >> >> >>> On Jun 27, 2024, at 3:03 PM, Josh McKenzie >> > wrote: >>> >>> +1 >>> >>> On Thu, Jun 27, 2024, at 12:40

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

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

+1 on the feature branch allowing breaking the effort into smaller chunks that can be even worked in parallel. > On Jul 1, 2024, at 3:13 AM, Štefan Miklošovič wrote: > > Hi Maxim, > > thank you for doing this. I think that Picocli is a great choice, comparing > it with airline v2 which is a

Re: [DISCUSS] CEP-42: Constraints Framework

Thanks everyone for all the feedback that came in after the call for votes. To Yifan's point, yes you are right, and I updated the CEP with the expressions. There’s been a really good discussion around adding or supporting constraints at read time. I think the point Doug made illustrate that suc

Re: [DISCUSS] CEP-42: Constraints Framework

o 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

Re: [DISCUSS] CEP-42: Constraints Framework

dad 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 Berna

Re: [DISCUSS] CEP-42: Constraints Framework

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, >> &g

[VOTE] CEP-42: Constraints Framework

at least 3 binding +1s and no binding vetoes. Thanks, Bernardo Botella

Re: [DISCUSS] CEP-42: Constraints Framework

ed out. But I don't see that as a reason not to go > forward with this feature. We should pick a path and accept the tradeoffs. > > Jordan > > > On Thu, Jun 13, 2024 at 2:39 PM Bernardo Botella > mailto:conta...@bernardobotella.com>> wrote: >> Thanks a

Re: [DISCUSS] Increments on non-existent rows in Accord

Doesn’t an UPDATE statement creates a row if the partition key does not exist? That’s also confirmed by the official Cassandra documentation here : ”Unlike in SQL, UPDATE does not check the prior existence of the ro

Re: [DISCUSS] CEP-42: Constraints Framework

Thanks a lot for your comments Abe! I do agree that the Constraint clause should be as simple as possible. I will add a note on the CEP along with some specifics about the proposed constraints (removing the ones that are contentious, and adding them to a possible future additions section). And

Re: [Discuss] CEP-24 Password validation and generation

+1 on Francisco’s comments. TCM is a general feature that a lot of other things will benefit from, and the fact that this CEP is one of those that will benefit shouldn’t block it from moving forward. > On Jun 11, 2024, at 11:16 PM, Francisco Guerrero wrote: > > Stefan, thanks for moving this C

Re: [DISCUSS] CEP-42: Constraints Framework

>> ... >>> ); >> >> Are these not just "CONSTRAINT inList([List of valid values], field);" and >> "CONSTRAINT not inList([List of valid values], field);"? >> At this point doesn't "CONSTRAINT p1 != p2" devolve to "C

Re: [DISCUSS] CEP-42: Constraints Framework

? > 3) What does "is it block listed" mean? > > In the meanwhile, I made changes to CEP-24 to move transactionality into > optional features. > > On Tue, Jun 11, 2024 at 12:18 AM Bernardo Botella > mailto:conta...@bernardobotella.com>> wrote: >> Hi eve

Re: [DISCUSS] CEP-42: Constraints Framework

Hi everyone, After the feedback, I'd like to make a recap of what we have discussed in this thread and try to move forward with the conversation. I made some clarifications: - Constraints are only applied at write time. - Guardrail configurations should maintain preference over what's being defi

Re: [DISCUSS] CEP-42: Constraints Framework

umn to form a composite object. Similar things should be supported at table level. I hope this helps, Bernardo > On Jun 6, 2024, at 11:08 PM, Dinesh Joshi wrote: > > On Thu, Jun 6, 2024 at 1:50 PM Bernardo Botella <mailto:conta...@bernardobotella.com>> wrote: >> I wi

Re: [DISCUSS] CEP-42: Constraints Framework

user. > > To me, punting on thinking through constraints kicks the most important can > down the road. > > Jon > > > On Tue, Jun 4, 2024 at 5:37 PM Bernardo Botella <mailto:conta...@bernardobotella.com>> wrote: >> In the CEP document there is

Re: [DISCUSS] CEP-42: Constraints Framework

ime getting on > board with new features where the main selling point is Extensibility over > the value they provide on their own. > > I think it would help a lot if we knew what types of constraints, besides the > size check, you were thinking of adding. > > Jon

Re: [DISCUSS] CEP-42: Constraints Framework

if constraints do not > violate them, then your query might fail or not based on what node is hit. > > I guess that guardrails would need to start to be transactional to be sure > this is avoided and guardrails are indeed same everywhere (CEP-24 thread sent > recently here in M

Re: [DISCUSS] CEP-42: Constraints Framework

what is in schema should win regardless of how guardrails are > configured. They don’t matter when a constraint is explicitly specified in a > schema. It should take the defaults in guardrails if there are any and no > constraint is specified on schema level. > > What

Re: [DISCUSS] CEP-42: Constraints Framework

;  >> Would this be implemented solely in the write path? Or would you also try to >> enforce it in the read and sstable/compaction/repair paths as well? >> >> >> >>> On May 31, 2024, at 23:24, Bernardo Botella >>> wrote: >>> >

[DISCUSS] CEP-42: Constraints Framework

Hello everyone, I am proposing this CEP: 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