>1. No. CQL did not "hurt me" and I'm not advocating we preserve CQL for posterity. Quite the opposite. I know you weren't at CoC, but my presentation was about how we move forward as a project. It will be available soon as a recording, but you can view the slides here: https://drive.google.com/file/d/1JCaWwLyniR-dNcsgdMVOLT2MfBcvvtTh/view?usp=sharing My recommendation to everyone was a move to supporting standard SQL syntax and freeze new CQL syntax. Supporting a similar-but-different SQL dialect in CQL is a liability we can easily fix. Formal proposal coming soon.
Overall, I believe we should steadily move Cassandra toward the SQL path. Nearly all major database systems are converging on SQL as the common language, and aligning with this ecosystem will ensure long-term interoperability, tooling support, and developer adoption. From a strategic perspective, embracing SQL is the right direction for the health and growth of the Cassandra project. However, at this stage, I do not think it is appropriate to outright disallow new CQL syntax extensions in the absence of a well-defined and community-approved plan for CQL→SQL convergence. Blocking proposals without such a roadmap could unnecessarily slow down innovation and discourage improvements that are valuable in the short to medium term. My position is that while I support eventual standardization with SQL, we should not hold up this particular CEP solely on that basis. Instead, once we as a community have developed and ratified a formal CEP that outlines the viability, scope, and migration strategy for transitioning from CQL to SQL, we should begin enforcing stricter rules around new syntax additions. At that point, contributors will have a clear framework to operate within, and we can ensure consistency without stalling progress in the interim. Jaydeep On Tue, Sep 16, 2025 at 7:28 PM Dinesh Joshi <[email protected]> wrote: > On Tue, Sep 16, 2025 at 12:05 PM Patrick McFadin <[email protected]> > wrote: > >> >> Generally, I'm -1 for adding more custom syntax. Another concern of mine >> is adding control plane actions in DDL. I understand the usefulness of a >> feature like this in ops. It's a great idea.. Here would be my counter >> proposal: >> >> - Leave the CQL as is and keep "CREATE ROLE" etc as is, and avoid making >> changes to core Cassandra. >> - Move the generation & policy to the sidecar project. A sidecar >> endpoint will generate the role name/password, enforce prefix/suffix/length >> requirements, ensure uniqueness, and then return the role and password (or >> a secret handle) to the caller. >> > > Why can’t we have both? Before you point out that this would be > “redundant” let me share my rationale. > > The Cassandra Sidecar should provide a stable API for managing different > versions of Cassandra. I would introduce this feature in the Sidecar for > all supported versions. This means operators can immediately use it without > worrying about the underlying version of Cassandra as long as it is > supported. This means the Sidecar will have to implement a similar logic > for older versions of Cassandra that won’t have the feature but that’s fine > as long as the operators derive value out of it. > > When we push this feature into Cassandra, the Sidecar just leverages that > functionality instead. This gets rid of the redundancy eventually when the > future supported versions get the functionality. > > This avoids expensive backports of such features. For those amongst the > community that run multiple versions of Cassandra, the cost of backporting > features in the older releases is not only invasive but also risky. The > above outlined strategy allows us to derisk and focus on validating newer > versions rather than backports to older versions. > > Dinesh >
