Re: [DISCUSS] How we version our releases

[Josh McKenzie]

> Does this imply that each release is allowed to make breaking changes 
> (assuming they followed the “correct” deprecation process)?  My first 
> instinct is to not like this
Does the clarification in the earlier thread help shift your perspective / 
address your concerns here David?

Will leave this thread for another 24 hours to see if there's any other 
concerns and call a vote if not.

Thanks everyone for the engagement.

On Fri, Apr 11, 2025, at 11:22 AM, Josh McKenzie wrote:
>> So we avoid 6.1, 7.2, etc?  Does this imply that each release is allowed to 
>> make breaking changes (assuming they followed the “correct” deprecation 
>> process)? 
> Yes and no.
> 
> A release can't make a breaking change *relative to the immediately preceding 
> release*, if something has been deprecated.
> 
> A release *can* make a breaking change *from another actively supported 
> release* if it's not an adjacent release and the feature was signaled as 
> deprecated in the interim release.
> 
> On Fri, Apr 11, 2025, at 10:39 AM, Jon Haddad wrote:
>> +1.
>> 
>> It's the proper signal to the community.  A .1 release could still be done 
>> as an exception, but I have a hard time thinking of a case other than 
>> supporting a newer JDK without any other changes. 
>> 
>> On Fri, Apr 11, 2025 at 7:19 AM Jeremiah Jordan  wrote:
>>> +1 from me.
>>> No more wondering what the next version number will be.
>>> No more wondering what version I can upgrade from to use the new release.
>>> 
>>> -Jeremiah
>>> 
>>> On Apr 10, 2025 at 3:54:13 PM, Josh McKenzie  wrote:
 
 This came up in the thread from Jon on "5.1 should be 6.0".
 
 I think it's important that our release versioning is clear and simple. 
 The current status quo of:
 - Any .MINOR to next MAJOR is supported  
 - Any .MAJOR to next MAJOR is supported  
 - We reserve .MAJOR for API breaking changes
 - except for when we get excited about a feature and want to .MAJOR to 
 signal that
 - or we change JDK's and need to signal that
 - or any of another slew of caveats that require digging into NEWS.txt 
 to see what the hell we're up to. :D
 - And all of our CI pain that ensues from the above
 
 In my opinion the above is overly complex and could use simplification. I 
 also believe us re-litigating this on every release is a waste of time and 
 energy that could better be spent elsewhere on the project or in life. 
 It's also a signal about how confusing our release versioning has been for 
 the community.
 
 Let's leave aside the decision about whether we scope releases based on 
 time or based on features; let's keep this to the discussion about how we 
 version our releases.
 
 So here's what I'm thinking: a new release strategy that doesn't use 
 .MINOR of semver. Goals:
 - Simplify versioning for end users
 - Provide clearer contracts for users as to what they can expect in 
 releases
 - Simplify support for us (CI, merges, etc)
 - Clarify our public API deprecation process
 
 Structure / heuristic:
 - Online upgrades are supported for all GA supported releases at time of 
 new .MAJOR
 - T-1 releases are guaranteed API compatible
 - We use a deprecate-then-remove strategy for API breaking changes
 
 This would translate into the following for our upcoming releases 
 (assuming we stick with 3 supported majors at any given time):
 6.0:
 - 5.0, 4.1, 4.0 online upgrades are supported (grandfather window)
 - We drop support for 4.0
 - API compatibility is guaranteed w/5.0
 7.0:
 - 6.0, 5.0, 4.1 online upgrades are supported (grandfather window)
 - We drop support for 4.1
 - API compatibility is guaranteed w/6.0
 8.0:
 - 7.0, 6.0, 5.0 online upgrades are supported (fully on new paradigm)
 - We drop support for 5.0
 - API compatibility guaranteed w/7.0
 
 So: what do we think?
> 

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

[Štefan Miklošovič]

_A bigger issue, is the actual behavior, in that you can say NOT NULL and
still easily get null values by not supplying the value.  The constraint is
more of a weakly applied suggestion._

This is not true. You can not really put there null. See other discussion
about this behaviour on ML.

On Wed, Apr 16, 2025 at 6:36 PM Jon Haddad  wrote:

> I think the world is fairly used to NOT NULL in line with the type.  I
> don't see much value in paving our own path for things that are established
> norms.  Let's not reinvent wheels that don't need reinventing.
>
> I also think it's fine if the generated CQL from describe doesn't match
> the user's input.  We already do this with all the table level fields that
> get added.  I'm not sure why we should care if a user drifts away from not
> null either.  I think these are pretty irrelevant details in the grand
> scheme of things.
>
> A bigger issue, is the actual behavior, in that you can say NOT NULL and
> still easily get null values by not supplying the value.  The constraint is
> more of a weakly applied suggestion.  I'm expecting a bit of confusion
> around this.  I wonder if it makes sense to not allow prepared INSERT
> statements that don't contain the field if it's null constrained, although
> it doesn't really help us in the case of an upsert.  It does narrow the
> edge case a bit, which could be argued is good or bad depending on
> someone's mood.
>
> I think it should be made clear that what we're really giving the user
> when we say `value check not null` is this:
>
> INSERT INTO blah (id, value) VALUES(?, ? not null);
>
> Does accord change the behavior of INSERT to actually mean INSERT and not
> UPSERT, or do you still have to specify IF NOT EXISTS?
>
> Jon
>
>
>
> On Wed, Apr 16, 2025 at 12:50 AM Štefan Miklošovič 
> wrote:
>
>> Maybe I am too naive and idealist but I can see a world where, even we
>> enable them to do it like "val int not null", after they describe a table
>> and they see "val int check not null" they start to use the latter form
>> because they would be tired of switching two forms in their head all the
>> time when they see that all other checks they want to specify have to be
>> specified in "val int check ..." form. They might actually start to
>> appreciate the unified fashion of it and they will themselves drift away
>> from "val int not null" eventually. I would :D.
>>
>> As we are among leaders in NoSQL databases we have also a great leverage
>> over how stuff is going to be used and we can actively form this space. We
>> do not need to just follow.
>>
>> I am open to supporting specifying "val int not null" _together with_
>> "val int check not null" form. Not _exclusively_ SQL syntax only. This
>> syntax sugar can go in anytime and it is more or less purely "additive".
>> Even if a user specifies it like "val int not null" it will be internally
>> stored as "val int check not null" to be consistent with how it is going to
>> be represented internally with all other checks. NOT NULL will ultimately
>> be a check as any other we have, it is just how it might be defined on the
>> CQL level which we are arguing about here.
>>
>> On Wed, Apr 16, 2025 at 12:56 AM Patrick McFadin 
>> wrote:
>>
>>> I may be to blame for some of that energy. :D
>>>
>>> No, we don't have consensus on that direction, but I think we will
>>> eventually. CQL started out as a subset of SQL but has drifted because
>>> features get added async and there just hasn't been any formal standard or
>>> road map or lofty goal. We've been laying out track in front of us as we go
>>> along. A couple of years ago, I had a conversation at ApacheCon, and it
>>> started slowly rattling around my brain that the developer experience
>>> destination is regression to a mean and not charting a bold new path.
>>> Everything else in Cassandra was already charting plenty of new paths, but
>>> if we give users a calm, familiar API, that feels like a winner. SQL is
>>> already a standard and could be our roadmap.
>>>
>>> With all that, I've been getting back into the data modeling game and
>>> seeing how a slightly different syntax can lead to angry users. In
>>> conversations with users, the idea of being SQL compatible in syntax
>>> (features can come whenever) is highly appealing. In reality, we are
>>> talking about CQL4, but why create tech debt for later if we design
>>> features now? My dream would be to have a compatibility test for Cassandra
>>> SQL that ticks off what's left for implementation. This is probably a
>>> DISCUSS thread but here we are now.
>>>
>>> Patrick
>>>
>>> On Tue, Apr 15, 2025 at 1:47 PM Josh McKenzie 
>>> wrote:
>>>
 If we have a goal of eventually providing ANSI SQL support one day, we
 should at least stick to the ANSI SQL standard where applicable for
 features in the meantime.

 Do we collectively have that goal? Not disagreeing with it at all,
 genuinely curious.

 Broadly I agree that we should definitely keep 

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

[Benedict]

I thought we had agreed previously that NOT NULL would require that you specify the value?Regarding Accord, great question Jon. I’m in favour of moving towards SQL semantics wherever possible, but I am uncertain how best to do it for features that are already in use. David has spotted some semantic “bugs” in LWTs that we will be patching in transactions, but I’m not sure if changing the behaviour of INSERT and UPDATE is right or not without a more general endeavour to standardise eg CQL4 with these semantics. I don’t have a super strong opinion, and am open to a broader consensus.Today though Accord maintains standard CQL semantics on the whole, on the assumption this will be less surprising to users.On 16 Apr 2025, at 17:36, Jon Haddad  wrote:I think the world is fairly used to NOT NULL in line with the type.  I don't see much value in paving our own path for things that are established norms.  Let's not reinvent wheels that don't need reinventing. I also think it's fine if the generated CQL from describe doesn't match the user's input.  We already do this with all the table level fields that get added.  I'm not sure why we should care if a user drifts away from not null either.  I think these are pretty irrelevant details in the grand scheme of things.A bigger issue, is the actual behavior, in that you can say NOT NULL and still easily get null values by not supplying the value.  The constraint is more of a weakly applied suggestion.  I'm expecting a bit of confusion around this.  I wonder if it makes sense to not allow prepared INSERT statements that don't contain the field if it's null constrained, although it doesn't really help us in the case of an upsert.  It does narrow the edge case a bit, which could be argued is good or bad depending on someone's mood.I think it should be made clear that what we're really giving the user when we say `value check not null` is this:INSERT INTO blah (id, value) VALUES(?, ? not null);Does accord change the behavior of INSERT to actually mean INSERT and not UPSERT, or do you still have to specify IF NOT EXISTS? JonOn Wed, Apr 16, 2025 at 12:50 AM Štefan Miklošovič  wrote:Maybe I am too naive and idealist but I can see a world where, even we enable them to do it like "val int not null", after they describe a table and they see "val int check not null" they start to use the latter form because they would be tired of switching two forms in their head all the time when they see that all other checks they want to specify have to be specified in "val int check ..." form. They might actually start to appreciate the unified fashion of it and they will themselves drift away from "val int not null" eventually. I would :D.As we are among leaders in NoSQL databases we have also a great leverage over how stuff is going to be used and we can actively form this space. We do not need to just follow. I am open to supporting specifying "val int not null" _together with_ "val int check not null" form. Not _exclusively_ SQL syntax only. This syntax sugar can go in anytime and it is more or less purely "additive". Even if a user specifies it like "val int not null" it will be internally stored as "val int check not null" to be consistent with how it is going to be represented internally with all other checks. NOT NULL will ultimately be a check as any other we have, it is just how it might be defined on the CQL level which we are arguing about here.On Wed, Apr 16, 2025 at 12:56 AM Patrick McFadin  wrote:I may be to blame for some of that energy. :D No, we don't have consensus on that direction, but I think we will eventually. CQL started out as a subset of SQL but has drifted because features get added async and there just hasn't been any formal standard or road map or lofty goal. We've been laying out track in front of us as we go along. A couple of years ago, I had a conversation at ApacheCon, and it started slowly rattling around my brain that the developer experience destination is regression to a mean and not charting a bold new path. Everything else in Cassandra was already charting plenty of new paths, but if we give users a calm, familiar API, that feels like a winner. SQL is already a standard and could be our roadmap. With all that, I've been getting back into the data modeling game and seeing how a slightly different syntax can lead to angry users. In conversations with users, the idea of being SQL compatible in syntax (features can come whenever) is highly appealing. In reality, we are talking about CQL4, but why create tech debt for later if we design features now? My dream would be to have a compatibility test for Cassandra SQL that ticks off what's left for implementation. This is probably a DISCUSS thread but here we are now. Patrick  On Tue, Apr 15, 2025 at 1:47 PM Josh McKenzie  wrote:If we have a goal of eventually providing ANSI SQL support one day, we should at least stick to the ANSI SQL standard whe

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

[Jon Haddad]

I think the world is fairly used to NOT NULL in line with the type.  I
don't see much value in paving our own path for things that are established
norms.  Let's not reinvent wheels that don't need reinventing.

I also think it's fine if the generated CQL from describe doesn't match the
user's input.  We already do this with all the table level fields that get
added.  I'm not sure why we should care if a user drifts away from not null
either.  I think these are pretty irrelevant details in the grand scheme of
things.

A bigger issue, is the actual behavior, in that you can say NOT NULL and
still easily get null values by not supplying the value.  The constraint is
more of a weakly applied suggestion.  I'm expecting a bit of confusion
around this.  I wonder if it makes sense to not allow prepared INSERT
statements that don't contain the field if it's null constrained, although
it doesn't really help us in the case of an upsert.  It does narrow the
edge case a bit, which could be argued is good or bad depending on
someone's mood.

I think it should be made clear that what we're really giving the user when
we say `value check not null` is this:

INSERT INTO blah (id, value) VALUES(?, ? not null);

Does accord change the behavior of INSERT to actually mean INSERT and not
UPSERT, or do you still have to specify IF NOT EXISTS?

Jon



On Wed, Apr 16, 2025 at 12:50 AM Štefan Miklošovič 
wrote:

> Maybe I am too naive and idealist but I can see a world where, even we
> enable them to do it like "val int not null", after they describe a table
> and they see "val int check not null" they start to use the latter form
> because they would be tired of switching two forms in their head all the
> time when they see that all other checks they want to specify have to be
> specified in "val int check ..." form. They might actually start to
> appreciate the unified fashion of it and they will themselves drift away
> from "val int not null" eventually. I would :D.
>
> As we are among leaders in NoSQL databases we have also a great leverage
> over how stuff is going to be used and we can actively form this space. We
> do not need to just follow.
>
> I am open to supporting specifying "val int not null" _together with_ "val
> int check not null" form. Not _exclusively_ SQL syntax only. This syntax
> sugar can go in anytime and it is more or less purely "additive". Even if a
> user specifies it like "val int not null" it will be internally stored as
> "val int check not null" to be consistent with how it is going to be
> represented internally with all other checks. NOT NULL will ultimately be a
> check as any other we have, it is just how it might be defined on the CQL
> level which we are arguing about here.
>
> On Wed, Apr 16, 2025 at 12:56 AM Patrick McFadin 
> wrote:
>
>> I may be to blame for some of that energy. :D
>>
>> No, we don't have consensus on that direction, but I think we will
>> eventually. CQL started out as a subset of SQL but has drifted because
>> features get added async and there just hasn't been any formal standard or
>> road map or lofty goal. We've been laying out track in front of us as we go
>> along. A couple of years ago, I had a conversation at ApacheCon, and it
>> started slowly rattling around my brain that the developer experience
>> destination is regression to a mean and not charting a bold new path.
>> Everything else in Cassandra was already charting plenty of new paths, but
>> if we give users a calm, familiar API, that feels like a winner. SQL is
>> already a standard and could be our roadmap.
>>
>> With all that, I've been getting back into the data modeling game and
>> seeing how a slightly different syntax can lead to angry users. In
>> conversations with users, the idea of being SQL compatible in syntax
>> (features can come whenever) is highly appealing. In reality, we are
>> talking about CQL4, but why create tech debt for later if we design
>> features now? My dream would be to have a compatibility test for Cassandra
>> SQL that ticks off what's left for implementation. This is probably a
>> DISCUSS thread but here we are now.
>>
>> Patrick
>>
>> On Tue, Apr 15, 2025 at 1:47 PM Josh McKenzie 
>> wrote:
>>
>>> If we have a goal of eventually providing ANSI SQL support one day, we
>>> should at least stick to the ANSI SQL standard where applicable for
>>> features in the meantime.
>>>
>>> Do we collectively have that goal? Not disagreeing with it at all,
>>> genuinely curious.
>>>
>>> Broadly I agree that we should definitely keep ourselves *compatible *with
>>> ANSI SQL where possible so as not to paint ourselves into a corner nor
>>> alienate our users, but I do believe there's value in having a consistent
>>> UX while acknowledging and accommodating that things aren't necessarily
>>> consistent in the SQL space.
>>>
>>> Are you against offering a superset of that standard (i.e. CHECK on all
>>> constraints a supported form, ANSI SQL standard on things like IS NOT NULL
>>> etc)?
>>>

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

[Štefan Miklošovič]

Maybe I am too naive and idealist but I can see a world where, even we
enable them to do it like "val int not null", after they describe a table
and they see "val int check not null" they start to use the latter form
because they would be tired of switching two forms in their head all the
time when they see that all other checks they want to specify have to be
specified in "val int check ..." form. They might actually start to
appreciate the unified fashion of it and they will themselves drift away
from "val int not null" eventually. I would :D.

As we are among leaders in NoSQL databases we have also a great leverage
over how stuff is going to be used and we can actively form this space. We
do not need to just follow.

I am open to supporting specifying "val int not null" _together with_ "val
int check not null" form. Not _exclusively_ SQL syntax only. This syntax
sugar can go in anytime and it is more or less purely "additive". Even if a
user specifies it like "val int not null" it will be internally stored as
"val int check not null" to be consistent with how it is going to be
represented internally with all other checks. NOT NULL will ultimately be a
check as any other we have, it is just how it might be defined on the CQL
level which we are arguing about here.

On Wed, Apr 16, 2025 at 12:56 AM Patrick McFadin  wrote:

> I may be to blame for some of that energy. :D
>
> No, we don't have consensus on that direction, but I think we will
> eventually. CQL started out as a subset of SQL but has drifted because
> features get added async and there just hasn't been any formal standard or
> road map or lofty goal. We've been laying out track in front of us as we go
> along. A couple of years ago, I had a conversation at ApacheCon, and it
> started slowly rattling around my brain that the developer experience
> destination is regression to a mean and not charting a bold new path.
> Everything else in Cassandra was already charting plenty of new paths, but
> if we give users a calm, familiar API, that feels like a winner. SQL is
> already a standard and could be our roadmap.
>
> With all that, I've been getting back into the data modeling game and
> seeing how a slightly different syntax can lead to angry users. In
> conversations with users, the idea of being SQL compatible in syntax
> (features can come whenever) is highly appealing. In reality, we are
> talking about CQL4, but why create tech debt for later if we design
> features now? My dream would be to have a compatibility test for Cassandra
> SQL that ticks off what's left for implementation. This is probably a
> DISCUSS thread but here we are now.
>
> Patrick
>
> On Tue, Apr 15, 2025 at 1:47 PM Josh McKenzie 
> wrote:
>
>> If we have a goal of eventually providing ANSI SQL support one day, we
>> should at least stick to the ANSI SQL standard where applicable for
>> features in the meantime.
>>
>> Do we collectively have that goal? Not disagreeing with it at all,
>> genuinely curious.
>>
>> Broadly I agree that we should definitely keep ourselves *compatible *with
>> ANSI SQL where possible so as not to paint ourselves into a corner nor
>> alienate our users, but I do believe there's value in having a consistent
>> UX while acknowledging and accommodating that things aren't necessarily
>> consistent in the SQL space.
>>
>> Are you against offering a superset of that standard (i.e. CHECK on all
>> constraints a supported form, ANSI SQL standard on things like IS NOT NULL
>> etc)?
>>
>> On Tue, Apr 15, 2025, at 3:05 AM, Benedict wrote:
>>
>>
>> I am not certain if the ANSI SQL standard requires that any expression be
>> supported, but either way it is much better to implement a strict subset of
>> a feature than to implement an overlapping feature we can never synchronise
>> with the standard.
>>
>> Accord is also capable of imposing multi column expressions without
>> constraining what user queries can do.
>>
>>
>>
>> On 15 Apr 2025, at 02:10, David Capwell  wrote:
>>
>> One argument I have against using columns in the constraint is that we
>> currently are not able to actually handle the CHECK spec in SQL.  In SQL
>> the CHECK expression is a valid search expression (eg. price > 42 AND tag =
>> ‘foo’), and is limited to the current row.
>>
>> Where we differ in Apache Cassandra
>>
>> 1) the mutation might not include the columns referenced in the search
>> expression: price numeric CHECK (name IS NOT NULL) (requires each mutation
>> to define all columns referenced in any constraint)
>> 2) our current checks are not normal search expressions (that limit
>> functions to deterministic ones), its a allowed listed set of expressions
>> (fixable)
>>
>> If we actually want to be the SQL version of constraints then we need to
>> put more restrictions on what people can do.
>>
>> For example
>>
>> price numeric CHECK (length(name) > 42)
>>
>> This constraint can only be handled if both price and name are present in
>> the query, so we would need to force all