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

On Sun, Apr 13, 2025 at 9:24 AM Patrick McFadin wrote: > I'm loving all the syntax discussion lately. It's a good debate and > essential for the project's future with a good developer experience. > +1 > On NULL. I've been asked this a million times by end users. Why is there > no "NOT NULL" in

Re: Huge NetApp donation of hardware for ci-cassandra

I am thrilled to hear this. I appreciate the donation! On Wed, Mar 19, 2025 at 11:20 AM Katona, Amanda via dev < dev@cassandra.apache.org> wrote: > [image: celebrate] Katona, Amanda reacted to your message: > -- > *From:* Dmitry Konstantinov > *Sent:* Wednesday, March

Re: [DISCUSS] Plugins and dependencies

Definitely supportive of modularizing code but from a developer productivity standpoint we should discuss the overhead of managing changes across multiple repos. On Sun, Mar 16, 2025 at 4:26 AM Benedict Elliott Smith wrote: > I want to break out at least one or two shared library projects. Both

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

+1 On Sun, Mar 9, 2025 at 5:18 AM Mick Semb Wever wrote: > Please vote on the acceptance of the Cassandra Cluster Manager (CCM) > and its IP Clearance: > https://incubator.apache.org/ip-clearance/cassandra-ccm.html > > All consent from original authors of the donation, and tracking of > collecte

Re: CEP-15 Update

Thank you for the update and a BIG thanks to all involved in getting us to this milestone. Looking forward to this work being merged in so we can kick the tires and help surface any issues early. On Tue, Mar 4, 2025 at 8:01 AM Benedict Elliott Smith wrote: > Hi everyone, > > It’s been exactly 3.

Re: [VOTE] Release Apache Sidecar Cassandra 0.1.0

+1, thanks to everyone who worked towards this milestone. On Fri, Feb 28, 2025 at 10:47 AM Doug Rohrer wrote: > +1 (nb) > > Thanks for putting in the work to get this ready to go! > > Doug > > > On Feb 28, 2025, at 7:46 AM, Brandon Williams wrote: > > > > +1, verified sigs/checksums, tested pac

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

On Mon, Feb 10, 2025 at 9:05 AM Bernardo Botella < conta...@bernardobotella.com> wrote: > We have consensus then. Let’s ditch the non strict version, and rename the > STRICTLY_NOT_NULL to NOT_NULL. > Can you give this thread at least 24-48 hours to ensure we capture any other perspectives?

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

In my head NOT_NULL constraint implies that the column must be specified on each write and must not be NULL. If a column with the NOT_NULL constraint is omitted during a write then shouldn’t it be treated as if it was specified and set to NULL? If the column has a non-NULL value that was previousl

Re: [DISCUSS] Fine grained max size guardails

Guardrails and constraints serve distinct purposes. Guardrails allow the operator to define reasonable bounds while constraints allow the developer to do the same in the schema. However the constraint should not violate the max bound of the guardrail. For example, if an operator defines the max siz

Re: [VOTE] CEP-45: Mutation Tracking

+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/display/CASSANDRA/CEP-45:+Mutation+Tracking > Discussion: > https://lists.apache.org/thread/0rstj4bzbb2596o5vw1m

Re: stalled PR #3585 (CASSANDRA-14098: integer overflow fix)

Hi Danny, Thanks for pinging this ist. It would be helpful for you to indicate on that JIRA that you're picking up the issue. Right now the JIRA is not assigned to anybody. I don't think you have a JIRA account. Could you please request[1] one? Once you have it, I will assign you the ticket and yo

Re: Status of CEP-1

wanted to give an update on where things stand > >>>>>>> with the Sidecar release. We've been working towards completing > >>>>>>> the remaining JIRAs[1][2][3][4][5][6] in preparation for the > Sidecar > >>>>>>> rele

Re: [DISCUSS] Bracing style on trunk

I honestly did not want to debate stylistic topics on a beautiful Saturday afternoon. As a project we have other, more pressing, topics to discuss. However, I just wanted to chime in and say that we have 3 options – 1. Continue placing the brace on a new line. 2. Move to accepting both new line br

Re: [DISCUSS] Review Guide for the project

As a growing community with new committers and contributors, I would support establishing a review guide to ensure consistency and uniformity of feedback. On Sat, Jan 18, 2025 at 5:21 AM Josh McKenzie wrote: > See thread "Checkstyle as style contract for Cassandra >

Re: Capabilities

Hi Jordan, Thank you for starting this thread. This is a great idea. From an ecosystem perspective this is absolutely critical. I'm a big +1 on working towards building this into Cassandra and the surrounding ecosystem. This would a step in the right direction to derisk upgrades. Dinesh On Wed,

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

On Mon, Dec 9, 2024 at 12:26 PM Jon Haddad wrote: > I hope I've made my point. The bar for merging in new functionality > should be higher. Features should work with 1TB of data on 3 nodes, that's > a low bar. I've spent at least a thousand hours over the last 5 years > developing the tooling

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

On Mon, Dec 9, 2024 at 10:52 AM Jeremy Hanna wrote: > In the case of UCS, is it in a beta state until we resolve the discussions > around UX/documentation? From a functional and production usage > perspective, it has been the only compaction strategy available for users > in DataStax's Astra man

Re: Re-evaluate compaction defaults in 5.1/trunk

To summarize, we only have 3 options here – 1. Make the default LCS and document this change. 2. Leave the default as STCS. 3. Leave the default undefined and force the operators to choose a compaction strategy. Given that there is apprehension on setting the default, I would suggest we provide n

Re: Re-evaluate compaction defaults in 5.1/trunk

On Sat, Dec 7, 2024 at 4:16 AM Brandon Williams wrote: > I agree with your sentiment here. It's a growing problem that we > don't have anyone focussed on writing user docs any longer - if you > open a ticket for docs, unfortunately you will probably need to drive > it for it to go anywhere. > H

Re: Re-evaluate compaction defaults in 5.1/trunk

On Fri, Dec 6, 2024 at 9:23 PM Jon Haddad wrote: > For a very common example, a lot of clusters are now using the k8ssandra > operator in AWS, which needs EBS. It's incredibly easy to fall behind on > compaction there. It's why I'm so interested in seeing CASSANDRA-15452 get > merged in. I've

Re: Re-evaluate compaction defaults in 5.1/trunk

t is a nightmare. > > Sorry, but you can't screw over 20% of the community to make life a little > better for the 80%. This is a terrible tradeoff. > > > Jon > > On Fri, Dec 6, 2024 at 8:36 PM Dinesh Joshi wrote: > >> I would argue that vast majority of real world

Re: Re-evaluate compaction defaults in 5.1/trunk

c 6, 2024, at 8:01 PM, Brad wrote: > > > Could you elaborate what you mean by 'disk storage management'? > > I often see clusters use LCS as an easy fix to avoid the 50% disk free > recommendation of STCS without considering the write > magnification implications. >

Re: Re-evaluate compaction defaults in 5.1/trunk

I have to agree with Chris here. In the vast majority of cases LCS hits the sweet spot and avoids the STCS pitfalls. UCS is too new and I would not make that a default OOTB. Philosophically, as a project, we should wait until critical features like these reach a certain level of maturity prior to

Re: Re-evaluate compaction defaults in 5.1/trunk

Could you elaborate what you mean by 'disk storage management'? On Fri, Dec 6, 2024 at 7:30 PM Brad wrote: > I'm -1 on LCS being the default, seen far too many people use it for disk > storage management > > On Fri, Dec 6, 2024 at 10:08 PM Jon Haddad > wrote: > >> I'm -1 on LCS being the defaul

Re: Status of CEP-1

a release of Sidecar. >>> > > > >>> > > > Looking forward to any feedback from the community. >>> > > > >>> > > > Best, >>> > > > - Saranya Krishnakumar & Francisco Guerrero >>> > > &g

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

Maxwell, here's the documentation for project governance for reference - https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance Like Stefan said, please wait until more binding +1s come in. I'm +1 on the CEP. thanks, Dinesh On Thu, Nov 7, 2024 at 7:51 AM Štefan Mik

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

+1 On Tue, 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: [DISCUSS] Usage of "var" instead of types in the code

I lean on the side of being explicit but I want to recognize that there are exceptions to every rule. There are situations where it might be acceptable to use var and may help productivity. We should enumerate it in our code style / developer docs. I think it is ok to use var in scripts or test cas

Re: [Discuss] Repair inside C*

On Mon, Oct 21, 2024 at 9:18 AM David Capwell wrote: > One thing to keep in mind is that larger clusters require you “smartly” > split the ranges else you nuke your cluster… knowing how to split requires > internal knowledge from the database which we could expose, but then we > need to expose a

Re: [Discuss] Repair inside C*

;> > > > >>> >> > > > >> > > > >>> This is looking strong, thanks Jaydeep. >> > > > >> > > > >>> >> > > > >> > > > >>> >> > > > > >> > > > >>> >> > > > >&g

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

+1 On Fri, Oct 18, 2024 at 11:09 AM Jon Haddad wrote: > +1 > > On Fri, Oct 18, 2024 at 10:51 AM Bernardo Botella < > conta...@bernardobotella.com> wrote: > >> +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

Re: [VOTE] Release Apache Cassandra 5.0.2

+1 On Wed, Oct 16, 2024 at 5:19 AM Mick Semb Wever wrote: > Proposing the test build of Cassandra 5.0.2 for release. > > sha1: f278f6774fc76465c182041e081982105c3e7dbb > Git: https://github.com/apache/cassandra/tree/5.0.2-tentative > Maven Artifacts: > https://repository.apache.org/content/repos

Re: Status of CEP-1

> > >> > >> > > > >> to this and that URL, I see all endpoints, I put the >> > >> payloads / >> > >> > >> > > parameters >> > >> > >> > > > >> for them and I can just directly call that, no messing >> with >> > >> curl / >> > >> &g

Re: Status of CEP-1

Currently the Sidecar has a lot of functionality that is immediately usable by the community. Apart from minor fixes, the AuthN/Z story would be wrapped up soon. Post this, I would propose moving forward with cutting a release with the existing feature set so we can get this in the hands of our com

Re: Status of CEP-1

CEP-1 is still completely relevant and we could send an update but as it stands right now we’ve made a ton of progress and would like to focus on getting to a release so it’s real for the community. On Mon, Sep 30, 2024 at 5:31 PM Patrick McFadin wrote: > There are two easy choices. > > 1 - Re-f

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

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 wrote: > I made the mistake of asking two things in one email. > > First thing I asked. Sidecar? Stalled CEP so why is this being talked > about like this is a thing

Re: [DISCUSSION] CEP-38: CQL Management API

no. Maxim and I have had some offline discussions. We need to make some changes before we can be ready to vote on it. On Thu, Sep 19, 2024 at 11:09 AM Patrick McFadin wrote: > There is no VOTE thread for this CEP. Is this ready for one? > > On Tue, Jan 9, 2024 at 3:28 AM Maxim Muzafarov wrote:

Re: [DISCUSS] CEP-31 negotiated authentication

This is an area of interest for me personally and is an important feature. Not sure if the original author is going to see it through since we've not had any discussion on it for a while. Is anybody interested in picking this up? Dinesh On Thu, Sep 19, 2024 at 10:54 AM Patrick McFadin wrote: >

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

Congratulations, everyone! On Thu, Sep 12, 2024 at 4:40 AM Mick Semb Wever wrote: > The PMC's members are pleased to announce that Chris Bannister, James > Hartig, Jackson Flemming and João Reis have accepted invitations to > become committers on the Drivers subproject. > > Thanks a lot for ever

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

My 2c are below – We have a patch that is preventing a known data loss issue. People may or may not know they're suffering from this issue so this should go in all supported versions of Cassandra with it enabled by default. Will this cause issues for operators? Sure. Is it worth keeping this featu

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

Congratulations to the both of you. Thank you for being valuable members of the Apache Cassandra community and all the hard work you have put in over the years! Dinesh On Fri, Aug 30, 2024 at 1:21 PM Jon Haddad wrote: > > The PMC's members are pleased to announce that Jordan West and Stefan > M

Re: 【DISCUSS】The configuration of Commitlog archiving

Thanks for bringing this to the mailing list. I quickly skimmed the feature and I agree with you that having an arbitrary command executed could be dangerous. However, this is a 12 year old feature and so am guessing there are people using it. As far as locking down the feature, I don't think it i

Welcome Doug Rohrer as Cassandra Committer

The Apache Cassandra PMC is thrilled to announce that Doug Rohrer has accepted the invitation to become a committer! Doug has worked on several aspects of Cassandra, Sidecar, and Analytics. Congratulations and welcome! The Apache Cassandra PMC members

Re: Implement details of Protocol v5 framing

Hi Vincent, This is the Cassandra user's mailing list. You can engage the Cassandra developers on dev@cassandra.apache.org mailing list. I have bcc'd the user list and added the dev list. To answer your question, the spec may have drifted and may require a fix. Please feel free to raise a jira an

Re: [VOTE] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

+1 I think this is a low risk change which is going to avoid duplication of effort so it is worth it. On Sat, Aug 3, 2024 at 11:19 PM Yifan Cai wrote: > Hi, > > I am proposing backporting CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0. > > There is a discussion thread >

Re: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

On Tue, Jul 30, 2024 at 11:47 AM Mick Semb Wever wrote: > This also incentivises intentionally not introducing support for that api > in older mainlines. We KISS, if the user wants that ecosystem benefit they > need to upgrade to at least mainline X. > > Once older mainlines have it then we have

Re: [DISCUSS] Backport CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0

Any change we bring to stable releases, even though it is non-user facing change, brings in the possibility of introducing bugs and / or unintended side effects. Therefore it is important to carefully consider the trade offs when we make changes to older releases. We also have a precedent to make c

Re: Welcome Joey Lynch as Cassandra PMC member

Congratulations, Joey! On Wed, Jul 24, 2024 at 12:26 PM Patrick McFadin wrote: > Every once in a while you see an announcement and think "Wasn't that > already a thing?" and then realize it wasn't. This is one of those times. > Congratulations Joey on the thing I thought you already were so clea

Re: [DISCUSS] Replace airlift/airline library with Picocli

On Tue, Jul 16, 2024 at 8:48 AM Jeff Jirsa wrote: > if it’s unmaintained, let’s remove it before we’re doing it on fire. > +1 Fire drills are never pleasant. CLI parsing isn't a huge area of personal interest to me. However, it presents a non-trivial attack surface as input processing is a rip

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

> We need to pick libraries based on their merits. Apple's draconian rules > should not prevent us from using the best option available. > > Jon > > > On Mon, Jul 8, 2024 at 12:57 PM Dinesh Joshi wrote: > >> I agree, having a DISCUSS thread with a specific subje

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

ted library, we will need a DISCUSS >> thread to add that new library (current protocol). This mostly just makes >> the pick more visible, and normally we only check simple things like “are >> we legally allowed to use” and “is this project dead?”. >> > >>

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: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

I don't personally think there is a strong need for a feature branch. If it makes it easy for you, please go ahead with a feature branch. One thing I had raised in the past was the desire to have a flag that would generate machine readable output for nodetool commands. If this can be done with a m

Re: [DISCUSS] CEP-42: Constraints Framework

t; >> I probably have not kept myself up to date with the discussion but I was >> thinking that constraints are effectively there just on the write path. >> Whatever is read is not a job of a constraint to refuse to return. >> >> On Tue, Jun 25, 2024 at 9:57 PM Dine

Re: [DISCUSS] CEP-42: Constraints Framework

Abe, that's a good point. We need to call out distinct use-cases here. When a fresh cluster is set up with constraints we don't have any issues because the data written and read back is going to be compliant to the constraint(s). For existing data in a cluster where new constraints are applied or e

Re: [VOTE][IP CLEARANCE] GoCQL driver

+1 Thank you Mick and everyone else involved in this effort. On Tue, Jun 25, 2024 at 11:12 AM Jeff Jirsa wrote: > +1 > > Thank you for being explicit about which authors of gocql have signed the > ICLA > > > Where The Gocql Authors for copyright purposes are below. Those marked > with > > aster

Re: [DISCUSS] CEP-42: Constraints Framework

On Tue, Jun 25, 2024 at 10:59 AM Josh McKenzie wrote: > > My intuition is the vote got called a *smidge* early but that things are > very much moving in the right direction and are very close. > Agreed and the vote thread got us more feedback which is valuable :)

Re: [DISCUSS] CEP-42: Constraints Framework

+1 on Doug's suggestion. The operator sets a limit that application developers should not be allowed to violate. This is precisely the type of safety that we should strive for. To Jordan's point, I also agree that the read before write type of constraints should be avoided but if there is a very g

Re: [DISCUSS] spark-cassandra-connector donation to Analytics subproject

This would be a great contribution to have for the Analytics subproject. The current bulk functionality in the Analytics subproject complements the spark-cassandra-connector so I see it as a good fit for donation. On Mon, Jun 24, 2024 at 12:32 AM Mick Semb Wever wrote: > > What are folks thought

Re: Cassandra PMC Chair Rotation, 2024 Edition

jeremiah.jor...@gmail.com> wrote: >>>> >>>> Welcome to the Chair role Dinesh! Congrats! >>>> >>>> On Jun 20, 2024 at 10:50:37 AM, Josh McKenzie >>>> wrote: >>>> >>>>> Another PMC Chair baton pass incoming! On

Re: [VOTE] CEP-24 Password validation / generation

+1. I have some minor feedback on how the configuration of different character classes works but that can be handled during the patch review. On Mon, Jun 17, 2024 at 2:32 AM Štefan Miklošovič wrote: > Hi everyone, > > I would like to start the voting for CEP-24 as all feedback in the > discussi

Re: [DISCUSS] CEP-42: Constraints Framework

On Thu, Jun 6, 2024 at 1:50 PM Bernardo Botella < conta...@bernardobotella.com> wrote: > I will update the CEP being specific with the two specific Constraint > types I will be adding, which are size and value (the ones shown in the > example). > Could you identify constraints for the most common

Re: [DISCUSS] CEP-42: Constraints Framework

On Thu, Jun 6, 2024 at 1:03 PM Štefan Miklošovič < stefan.mikloso...@gmail.com> wrote: > It is interesting to see this feedback. When I look at CEP-24 where I am > obsessing about a user being able to misconfigure the password validation > strength so if a user hits a "weak" node then she would be

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.1 (2nd attempt)

+1 verified hashes and signatures. On Tue, May 21, 2024 at 4:00 PM Bret McGuire wrote: >Greetings all! We're going to give this another go. > >Apologies for the confusion that sprang out of our last attempt. It > appears that the Nexus staging repository for the 4.18.1 release was > a

Re: [VOTE] Release Apache Cassandra 4.1.5

+1 On Fri, May 17, 2024 at 10:53 AM Brandon Williams < brandonwilli...@apache.org> wrote: > Friendly reminder that this vote is still open and lacks one binding > vote to pass. > > On Thu, May 2, 2024 at 11:36 AM Brandon Williams > wrote: > > > > Proposing the test build of Cassandra 4.1.5 for r

Re: Is there appetite to maintain the gocql driver (in the drivers subproject) ?

On Wed, May 15, 2024 at 12:09 AM Mick Semb Wever wrote: > Yes Dinesh. João Reis managed to get hold of both Chris and Martin. >>> Responses have been slow, but everyone is on board. This is not to be >>> considered a hostile fork, despite in all likelihood not being able to do a >>> full IP do

Re: Is there appetite to maintain the gocql driver (in the drivers subproject) ?

On Tue, May 14, 2024 at 10:05 AM Mick Semb Wever wrote: > > Ok, so we're got confidence now on how to approach this, confirmation from > the project's maintainers supporting it, and interest from a handful of > people interested in maintaining and contributing to the project. > Did you talk to t

Fwd: Save the Date: Apache At Visa Summit on May 16, 2024 ( Registration Open.)

FYI, if anybody is interested in this event today is the registration deadline. -- Forwarded message - From: Battula, Brahma Reddy Date: Mon, Apr 29, 2024 at 10:27 AM Subject: Re: Save the Date: Apache At Visa Summit on May 16, 2024 ( Registration Open.) To: d...@community.apache.

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

On Tue, Apr 23, 2024 at 11:37 AM Venkata Hari Krishna Nukala < n.v.harikrishna.apa...@gmail.com> wrote: > reason why I called out binary level verification out of initial scope is > because of these two reasons: 1) Calculating digest for each file may > increase CPU utilisation and 2) Disk would a

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

I am not familiar with ECS but if we’re going to go for it I would prefer it to be a sub project really. Jon, what do you think? On Thu, Apr 25, 2024 at 2:44 PM Brandon Williams wrote: > I want to begin by saying I am generally +1 on this because I have > become a fan of easy-cass-stress after u

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

On Thu, Apr 18, 2024 at 12:46 PM Ariel Weisberg wrote: > > If there is a faster/better way to replace a node why not have Cassandra > support that natively without the sidecar so people who aren’t running the > sidecar can benefit? > I am not the author of the CEP so take whatever I say with a

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

On Fri, Apr 19, 2024 at 3:12 PM Jon Haddad wrote: > I haven't looked at streaming over TLS, so I might be way off base here, > but our own docs ( > https://cassandra.apache.org/doc/latest/cassandra/architecture/streaming.html) > say ZCS is not available when using encryption, and if we have to br

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

On Mon, Apr 8, 2024 at 10:23 AM Jon Haddad wrote: > This seems like a lot of work to create an rsync alternative. I can't > really say I see the point. I noticed your "rejected alternatives" > mentions it with this note: > I want to point out a few things before dismissing it as an 'rsync alte

Re: Is there appetite to maintain the gocql driver (in the drivers subproject) ?

If we take this on - are there any active contributors that can be raised as committers to maintain this project? On Wed, Apr 3, 2024 at 2:36 PM Nate McCall wrote: > We've talked through this before. Benjamin sussed out the main issue, > IIRC. > tl,dr: > - The AUTHORS lists everyone who ever mad

Re: [DISCUSS] Modeling JIRA fix version for subprojects

hi folks - sorry to have dropped the ball on responding to this thread. My 2 cents are as follows - 1. Having a separate JIRA project for each sub-project will add management overhead. This option, however, allows us to model unique workflows for the sub-project. 2. Managing the sub-project as p

Re: [Discuss] Introducing Flexible Authentication in Cassandra via Feature Flag

Hi Gaurav, Thank you for the document. I read through it and wasn't entirely clear about the problem you're trying to solve. If you're talking about enabling authentication for the very first time on a cluster which does not have any authentication then there are different ways of handling it. >

Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

e hardware which are not compatible with zlib. With this approach we > could enable those features as well. > > > > We are also planning to accelerate existing compressors, if that is the > preferred approach we will try to come up with a solution to work around > the 4k window

Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

Shylaja, Cassandra uses ZStd, LZ4 and other compression libraries via JNI to compress data. The intel hardware accelerator support is integrated into those libraries and we can benefit from it. If there are special parameters that need to be passed in to these libraries we can make those changes o

Re: Custom FSError and CommitLog Error Handling

> On Dec 11, 2023, at 11:27 AM, Raymond Huffman > wrote: > > On our fork of Cassandra, we've implemented some custom behavior for handling > CommitLog and SSTable Corruption errors. Specifically, if a node detects one > of those errors, we want the node to stop itself, and if the node is > re

Re: [ATTENTION] Forced push on cassandra-5.0 branch !!!

thanks for the heads up. Is there anything we could do to avoid bad merges in the future? Dinesh > On Dec 16, 2023, at 3:26 PM, Mick Semb Wever wrote: > > > The cassandra-5.0 branch accidentally got 229 trunk merge commits brought > into it. > > This has been fixed now, but required a force

Re: Future direction for the row cache and OHC implementation

> On Dec 14, 2023, at 5:35 PM, Paulo Motta wrote: > > This could be a potential hook for out-of-process caching. > > Would something like this be valuable/feasible? It is certainly feasible. I am not sure about its value. Dinesh

Re: Future direction for the row cache and OHC implementation

I would avoid taking away a feature even if it works in narrow set of use-cases. I would instead suggest - 1. Leave it disabled by default. 2. Detect when Row Cache has a low hit rate and warn the operator to turn it off. Cassandra should ideally detect this and do it automatically. 3. Move to C

Re: Future direction for the row cache and OHC implementation

> On Dec 14, 2023, at 10:32 AM, Ariel Weisberg wrote: > > 1. Fork OHC and start publishing under a new package name and continue to use > it Who would fork it? Where would you fork it? My first instinct is that this would not be viable path forward. > 2. Replace OHC with a different cache imp

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.0

+1On Dec 8, 2023, at 11:43 PM, Mick Semb Wever wrote:Proposing the test build of Cassandra Java Driver 4.18.0 for release.sha1: 105d378fce16804a8af4c26cf732340a0c63b3c9Git: https://github.com/apache/cassandra-java-driver/tree/4.18.0Maven Artifacts:https://repository.apache.org/content/repositorie

Welcome Francisco Guerrero Hernandez as Cassandra Committer

The PMC members are pleased to announce that Francisco Guerrero Hernandez has accepted the invitation to become committer today. Congratulations and welcome! The Apache Cassandra PMC members

Re: [DISCUSSION] CEP-38: CQL Management API

Hi Maxim, Thanks for putting this CEP together! This is a great start. I have gone over the CEP and there is one thing that stuck out to me. Among the 'basic requirements', I see you have this - > A dedicated admin port with the native protocol behind it, > allowing only admin commands, to add

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

I have a strong preference to move out the 5.0 date to have accord and TCM. I don’t see the point in shipping 5.0 without these features especially if 5.1 is going to follow close behind it. Dinesh > On Oct 23, 2023, at 4:52 AM, Mick Semb Wever wrote: > >  > > The TCM work (CEP-21) is in it

Re: [DISCUSS] CommitLog default disk access mode

I haven't looked at the patch yet so take whatever I say here with a pinch of salt. Philosophically, defaults should not change unless there is a clear demonstrable benefit in majority cases for our users. In this case DirectIO should have clear benefits. That said, this is a new feature and I

Re: [VOTE] Accept java-driver

+1 This is great for the project. Thank you for all the hard work everyone put into this! It has been a long journey to get to this point. Dinesh > On Oct 2, 2023, at 9:53 PM, Mick Semb Wever wrote: > >  > The donation of the java-driver is ready for its IP Clearance vote. > https://incubato

Re: [VOTE] Release dtest-api 0.0.16

don Williams wrote: >>> +1 >>> >>> Kind Regards, >>> Brandon >>> >>> On Wed, Aug 16, 2023 at 4:34 PM Dinesh Joshi >> <mailto:djo...@apache.org>> wrote: >>> > >>> > Proposing the test bui

[VOTE] Release dtest-api 0.0.16

Proposing the test build of in-jvm dtest API 0.0.16 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/1ba6ef93d0721741b5f6d6d72cba3da03fe78438 tagged with 0.0.16 Artifacts: http

Re: [Discuss] ​​CEP-35: Add PIP support for CQLSH

Brad, Thanks for starting this discussion. My understanding is that we're simply adding pip support for cqlsh and Apache Cassandra project will officially publish a cqlsh pip package. This is a good goal but other than having an official pip package, what is it that we're gaining? Please don't int

Re: [DISCUSS] Using ACCP or tc-native by default

+1 to on by default. I see the concern about breaking users by introducing 'silent defaults'. IMO ACCP itself is a non-breaking change. If I have missed something please point it out and I'll happy to reconsider my position. The advantages of having ACCP on by default far outweigh the risk of n

Re: August 5.0 Freeze (with waivers…) and a 5.0-alpha1

Mick, This sounds like a good plan. CEP-33 and 34 are ready to go. We're running into CI related issues but once they clear up we'll merge them. I anticipate we'll be done in a week's time. Thanks, Dinesh > On Jul 26, 2023, at 3:27 PM, Mick Semb Wever wrote: > > > The previous thread¹ on w

Re: [Discuss] Repair inside C*

I concur, repair is an intrinsic part of the database and belongs inside it. We can certainly expose a REST control plane API via the sidecar for triggering it on demand, scheduling, etc. That said, there are various implementation of repair scheduling and orchestration that a lot of organizati

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

+1 > On Jul 21, 2023, at 11:07 AM, Francisco Guerrero wrote: > > +1 (nb). This is a very valuable enhancement for the project. > > Thanks for the contribution, Jyothsna! > > On 2023/07/21 16:57:45 Jyothsna Konisa wrote: >> Hi Everyone! >> >> I would like to start a vote thread for CEP-34. >>

Re: Cassandra Sidecar CI is now green!

Thanks Francisco, Mick and Yifan for making this happen! > On Jul 20, 2023, at 4:00 PM, Francisco Guerrero wrote: > > Hi list, > > I wanted to bring some visibility into the Cassandra Sidecar CI health [1]. > It seems like it has been broken for quite a while and we have finally fixed > it toda

Re: [VOTE] Release Apache Cassandra 4.1.3

+1 > On Jul 18, 2023, at 11:28 PM, Miklosovic, Stefan > wrote: > > Proposing the test build of Cassandra 4.1.3 for release. > > sha1: 2a4cd36475de3eb47207cd88d2d472b876c6816d > Git: https://github.com/apache/cassandra/tree/4.1.3-tentative > Maven Artifacts: > https://repository.apache.org/c

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

Does anybody have any questions / comments? Dinesh > On Jul 17, 2023, at 12:37 PM, Dinesh Joshi wrote: > > Hi folks, > > Given the feedback received, we thought it would be best to do a CEP. Here's > the link: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

nd start a VOTE thread for it. Thanks, Dinesh > On Jul 12, 2023, at 12:13 AM, Dinesh Joshi wrote: > > I can certainly start a VOTE thread for the CQL syntax addition. There > hasn't been any feedback that suggests that there is an unaddressed > concern to the changes we are m

  1   2   3   4   >