> It could also be that nobody's willing to actually do it for real, in which > case it's all talk and there's no decision to make. I know of at least 2 groups running thousands of C* clusters w/projects in front of them exposing different APIs than CQL so there's definitely people willing to do it for real. Now, those being subprojects and subject to the dev cycles and community ergonomics of an Apache Foundation project are a different story. :)
I think a recurring SIG to explore that (or even just a one-off-advertised-here-higher-bandwidth community discussion about it we bring back to the list) would be super interesting and I'd be willing to donate an hour of my life to that. These patterns of things people do redundantly in orbit around our core project always capture my imagination. /shrug On Tue, Nov 4, 2025, at 2:56 PM, Jeff Jirsa wrote: > > > On 2025/11/04 19:42:31 Patrick McFadin wrote: > > Just to be clear, in my initial proposal I said that CQL can never go away. > > It’s a life sentence. Knowing the upgrade cycle that many users are on, it > > will be 50 years before we could even try. > > > > I feel we are at a fork here in the discussion. > > > > Fork 1: Discuss and somehow ratify that we adhere to SQL syntax for new CQL > > features > > > > Fork 2: Formation of a SIG or new DISCUSS thread on how to add SQL as a > > formal path. There have already been throwing around really good ideas and > > should continue. Josh wrapped it up nicely with a “Stateless layer that > > could serve many purposes” > > > Joel said this a while back: > > Conversion doesn't seem practical or desirable: it'd probably result in CQL > and a muddled version of SQL which wouldn't be beneficial for anyone. > > I agree with that, and I'd vote accordingly if someone wanted to ratify your > fork 1. > > Your fork 2 may or may not need to exist. You don't strictly NEED a SIG, > because you don't need changes in the database to implement it. It could be a > subproject. It could also be an external project. It could also be that > nobody's willing to actually do it for real, in which case it's all talk and > there's no decision to make. I think if someone wants to write a CEP that > exposes lower layer primitives to someone building layers, write the CEP and > negotiate it, great. If someone wants to write an official project-inclusive > CEP for a real SQL layer, write it and negotiate it. If someone wants to do > JOINs for CQL, fine, go for it (is that CEP already around? Ir might be). > > Right now all we have is a proposal to constrain CQL to be SQL compatible, > and at least a handful of people have argued about why that's probably a bad > idea. > > > >
