[VOTE] Release Apache Cassandra 5.0-rc1

[Mick Semb Wever]

Proposing the test build of Cassandra 5.0-rc1 for release.

sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/5.0-rc1/

The vote will be open for 72 hours (longer if needed). Everyone who has
tested the build is invited to vote. Votes by PMC members are considered
binding. A vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt:
https://github.com/apache/cassandra/blob/5.0-rc1-tentative/CHANGES.txt
[2]: NEWS.txt:
https://github.com/apache/cassandra/blob/5.0-rc1-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 5.0-rc1

[Mick Semb Wever]

.

Proposing the test build of Cassandra 5.0-rc1 for release.
>
> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/
>


The three green CI runs for this are
-
https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-2
-
https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-3
-
https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-4

Re: [DISCUSS] CEP-42: Constraints Framework

[Bernardo Botella]

Got it. Thanks for the clarification Jon. Then, in terms of syntax, I think we 
can discard the option 2.

In terms of GUARDRAIL vs CONSTRAINT concept you bring up, I guess here we have 
pros and cons for both sides. It is true that there is an existing concept of 
GUARDRAIL on Cassandra, and that reusing it comes with benefits. But, in my 
opinion, there are two main advantages to use the CONSTRAINT name for the 
feature:
- It keeps consistency with concepts from other databases (this may be a minor, 
but I really think there is benefit for those coming from other databases, and 
may help them understand what this actually is)
- Having it presented as a different concept help illustrate how those two 
features are different. Following the example provided by Doug, we can have 
clear separation on those two levels of restrictions to a write.



> On Jun 24, 2024, at 9:46 PM, Jon Haddad  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 Bernardo Botella 
> mailto:conta...@bernardobotella.com>> wrote:
>> Hi Ariel and Jon,
>> 
>> Let me address your question first. Yes, AND is supported in the proposal. 
>> Below you can find some examples of different constraints applied to the 
>> same column.
>> 
>> As per the LENGTH name instead of sizeOf as in the proposal, I am also not 
>> opposed to it if it is more consistent with terminology in the databases 
>> universe.
>> 
>> So, to recap, there seems to be general agreement on the usefulness of the 
>> Constraints Framework.
>> Now, from the feedback that has arrived after the voting has been called, I 
>> see there are three different proposals for syntax:
>> 
>> 1.-
>> The syntax currently described in the CEP. Example:
>> CREATE TYPE keyspace.cidr_address_ipv4 (
>>   ip_adress inet,
>>   subnet_mask int,
>>   CONSTRAINT subnet_mask > 0,
>>   CONSTRAINT subnet_mask < 32
>> )
>> 
>> 2.-
>> As Jon suggested, leaving this definitions to more specific Guardrails at 
>> table level. Example, something like:
>> column_min_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 0
>> column_max_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 32
>> 
>> 3.-
>> As Ariel suggested, having the CHECK keyword added to align consistency with 
>> SQL. Example:
>> CREATE TYPE keyspace.cidr_address_ipv4 (
>>   ip_adress inet,
>>   subnet_mask int,
>>   CONSTRAINT CHECK subnet_mask > 0,
>>   CONSTRAINT CHECK subnet_mask < 32
>> )
>> 
>> For the guardrails vs cql syntax, I think that keeping the conceptual 
>> separation that has been explored in this thread, and perfectly recapped by 
>> Doug, is closer to what we are trying to achieve with this framework. In my 
>> opinion, having them in the CQL schema definition provides those application 
>> level constraints that Doug mentions in an more accesible way than having to 
>> configure such specific guardrais.
>> 
>> For the addition of the CHECK keyword, I'm definitely not opposed to it if 
>> it helps Cassandra users coming from other databases understand concepts 
>> that were already familiar to them.
>> 
>> I hope this helps move the conversation forward,
>> Bernardo
>> 
>> 
>> 
>>> On Jun 24, 2024, at 12:17 PM, Ariel Weisberg >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I see a vote for this has been called. I should have provided more prompt 
>>> feedback sooner.
>>> 
>>> I am a strong +1 on adding column level constraints being a good thing to 
>>> add. I'm not too concerned about row/partition/table level constraints, but 
>>> I would like to change the syntax before I would be +1 on this CEP.
>>> 
>>> It would be good to align the syntax as closely as possible to our existing 
>>> syntax, and if not that then MySQL/Postgres. For example it looks like we 
>>> don't have a string length function so maybe add `LENGTH` (consistent with 
>>> MySQL/Postgres) to also use with column level constraints.
>>> 
>>> It looks like there are generally two forms of constraint syntax, one is 
>>> expressed as part of the column definition, and the other is a named or 
>>> anonymous constraint on the table. 
>>> https://www.w3schools.com/sql/sql_check.asp
>>> 
>>> Can we align with having these column level ones as `CHECK` constraints 
>>> like in SQL, and `CONSTRAINT [constraint_name] CHECK` would be used if 
>>> creating a named or multi-column constraint?
>>> 
>>> Will column level check constraints support `AND` so that you can specify 
>>> multiple constraints on the column? I am not sure if that is supported in 
>>> other databases, but it would be good to 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) will

Re: [DISCUSS] CEP-42: Constraints Framework

[Ariel Weisberg]

Hi,

I am also +1 on Doug's distinction between things that can be managed by 
operators and things that can be managed by applications.

Some things to note about the syntax is that there are parens around the 
condition in SQL. In your example there are multiple anonymous constraints on 
the same column, how are anonymous constraints handled? Does the database 
automatically generate a named constraint for them so they can be referenced 
later? Do we allow multiple constraints on the same column and AND them 
together?

Ariel



On Mon, Jun 24, 2024, at 6:43 PM, Bernardo Botella wrote:
> Hi Ariel and Jon,
> 
> Let me address your question first. Yes, AND is supported in the proposal. 
> Below you can find some examples of different constraints applied to the same 
> column.
> 
> As per the LENGTH name instead of sizeOf as in the proposal, I am also not 
> opposed to it if it is more consistent with terminology in the databases 
> universe.
> 
> So, to recap, there seems to be general agreement on the usefulness of the 
> Constraints Framework.
> Now, from the feedback that has arrived after the voting has been called, I 
> see there are three different proposals for syntax:
> 
> 1.-
> The syntax currently described in the CEP. Example:
> CREATE TYPE keyspace.cidr_address_ipv4 (
>   ip_adress inet,
>   subnet_mask int,
>   CONSTRAINT subnet_mask > 0,
>   CONSTRAINT subnet_mask < 32
> )
> 
> 2.-
> As Jon suggested, leaving this definitions to more specific Guardrails at 
> table level. Example, something like:
> column_min_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 0
> column_max_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 32
> 
> 3.-
> As Ariel suggested, having the CHECK keyword added to align consistency with 
> SQL. Example:
> CREATE TYPE keyspace.cidr_address_ipv4 (
>   ip_adress inet,
>   subnet_mask int,
>   CONSTRAINT CHECK subnet_mask > 0,
>   CONSTRAINT CHECK subnet_mask < 32
> )
> 
> For the guardrails vs cql syntax, I think that keeping the conceptual 
> separation that has been explored in this thread, and perfectly recapped by 
> Doug, is closer to what we are trying to achieve with this framework. In my 
> opinion, having them in the CQL schema definition provides those application 
> level constraints that Doug mentions in an more accesible way than having to 
> configure such specific guardrais.
> 
> For the addition of the CHECK keyword, I'm definitely not opposed to it if it 
> helps Cassandra users coming from other databases understand concepts that 
> were already familiar to them.
> 
> I hope this helps move the conversation forward,
> Bernardo
> 
> 
> 
>> On Jun 24, 2024, at 12:17 PM, Ariel Weisberg  wrote:
>> 
>> Hi,
>> 
>> I see a vote for this has been called. I should have provided more prompt 
>> feedback sooner.
>> 
>> I am a strong +1 on adding column level constraints being a good thing to 
>> add. I'm not too concerned about row/partition/table level constraints, but 
>> I would like to change the syntax before I would be +1 on this CEP.
>> 
>> It would be good to align the syntax as closely as possible to our existing 
>> syntax, and if not that then MySQL/Postgres. For example it looks like we 
>> don't have a string length function so maybe add `LENGTH` (consistent with 
>> MySQL/Postgres) to also use with column level constraints.
>> 
>> It looks like there are generally two forms of constraint syntax, one is 
>> expressed as part of the column definition, and the other is a named or 
>> anonymous constraint on the table. 
>> https://www.w3schools.com/sql/sql_check.asp
>> 
>> Can we align with having these column level ones as `CHECK` constraints like 
>> in SQL, and `CONSTRAINT [constraint_name] CHECK` would be used if creating a 
>> named or multi-column constraint?
>> 
>> Will column level check constraints support `AND` so that you can specify 
>> multiple constraints on the column? I am not sure if that is supported in 
>> other databases, but it would be good to 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) will deterministically agree on the constraints being 
>> enforced BUT... this also has to map to how/when constraints are enforced.
>> 
>> Both Accord and Paxos work best when the constraints are enforced when the 
>> final mutation to be applied 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,
>>> 
>>> I am proposing this CEP:
>>> CEP-42: Constraints Framework - CASSANDRA - Apache Software Foundation 
>>> 
>>> cwiki.apache.org 
>>>

Re: [DISCUSS] CEP-42: Constraints Framework

[Dinesh Joshi]

+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 good case for it, we
can discuss it.

We should also consider adding a NOT NULL constraint on columns. This will
allow applications to model columns that are mandatory for INSERT and
UPDATEs.




On Tue, Jun 25, 2024 at 9:24 AM Ariel Weisberg  wrote:

> Hi,
>
> I am also +1 on Doug's distinction between things that can be managed by
> operators and things that can be managed by applications.
>
> Some things to note about the syntax is that there are parens around the
> condition in SQL. In your example there are multiple anonymous constraints
> on the same column, how are anonymous constraints handled? Does the
> database automatically generate a named constraint for them so they can be
> referenced later? Do we allow multiple constraints on the same column and
> AND them together?
>
> Ariel
>
>
>
> On Mon, Jun 24, 2024, at 6:43 PM, Bernardo Botella wrote:
>
> Hi Ariel and Jon,
>
> Let me address your question first. Yes, AND is supported in the proposal.
> Below you can find some examples of different constraints applied to the
> same column.
>
> As per the LENGTH name instead of sizeOf as in the proposal, I am also not
> opposed to it if it is more consistent with terminology in the databases
> universe.
>
> So, to recap, there seems to be general agreement on the usefulness of the
> Constraints Framework.
> Now, from the feedback that has arrived after the voting has been called,
> I see there are three different proposals for syntax:
>
> 1.-
> The syntax currently described in the CEP. Example:
> CREATE TYPE keyspace.cidr_address_ipv4 (
>   ip_adress inet,
>   subnet_mask int,
>   CONSTRAINT subnet_mask > 0,
>   CONSTRAINT subnet_mask < 32
> )
>
> 2.-
> As Jon suggested, leaving this definitions to more specific Guardrails at
> table level. Example, something like:
> column_min_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 0
> column_max_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 32
>
> 3.-
> As Ariel suggested, having the CHECK keyword added to align consistency
> with SQL. Example:
> CREATE TYPE keyspace.cidr_address_ipv4 (
>   ip_adress inet,
>   subnet_mask int,
>   CONSTRAINT CHECK subnet_mask > 0,
>   CONSTRAINT CHECK subnet_mask < 32
> )
>
> For the guardrails vs cql syntax, I think that keeping the conceptual
> separation that has been explored in this thread, and perfectly recapped by
> Doug, is closer to what we are trying to achieve with this framework. In my
> opinion, having them in the CQL schema definition provides those
> application level constraints that Doug mentions in an more accesible way
> than having to configure such specific guardrais.
>
> For the addition of the CHECK keyword, I'm definitely not opposed to it if
> it helps Cassandra users coming from other databases understand concepts
> that were already familiar to them.
>
> I hope this helps move the conversation forward,
> Bernardo
>
>
>
> On Jun 24, 2024, at 12:17 PM, Ariel Weisberg  wrote:
>
> Hi,
>
> I see a vote for this has been called. I should have provided more prompt
> feedback sooner.
>
> I am a strong +1 on adding column level constraints being a good thing to
> add. I'm not too concerned about row/partition/table level constraints, but
> I would like to change the syntax before I would be +1 on this CEP.
>
> It would be good to align the syntax as closely as possible to our
> existing syntax, and if not that then MySQL/Postgres. For example it looks
> like we don't have a string length function so maybe add `LENGTH`
> (consistent with MySQL/Postgres) to also use with column level constraints.
>
> It looks like there are generally two forms of constraint syntax, one is
> expressed as part of the column definition, and the other is a named or
> anonymous constraint on the table.
> https://www.w3schools.com/sql/sql_check.asp
>
> Can we align with having these column level ones as `CHECK` constraints
> like in SQL, and `CONSTRAINT [constraint_name] CHECK` would be used if
> creating a named or multi-column constraint?
>
> Will column level check constraints support `AND` so that you can specify
> multiple constraints on the column? I am not sure if that is supported in
> other databases, but it would be good to 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) will deterministically agree on the constraints being
> enforced BUT... this also has to map to how/when constraints are enforced.
>
> Both Accord and Paxos work best when the constraints are enforced when the
> final mutation to be applied is created 

[VOTE][IP CLEARANCE] GoCQL driver

[Mick Semb Wever]

Please vote on the acceptance of the GoCQL driver and its IP Clearance:
https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html

All consent from original authors of the donation, and tracking of
collected CLAs, is found in:
 - https://github.com/gocql/gocql/issues/1751
 -
https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485

These do not require acknowledgement before the vote.

The code is prepared for donation at https://github.com/gocql/gocql

Once this vote passes we will request ASF Infra to move the gocql/gocql
as-is to apache/cassandra-gocql-driver  . The master branch and tags, with
all their history, will be kept.  Because consent and CLAs were not
received from all original authors the source files keep additional
reference to their earlier copyright authors and license.

This will become part of the Drivers subproject, ref CEP-8:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation

PMC members, please check carefully the IP Clearance requirements before
voting.

The vote will be open for 72 hours (or longer). Votes by PMC members are
considered binding. A vote passes if there are at least three binding +1s
and no -1's.

regards,
Mick

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Mick Semb Wever]

  .


> The vote will be open for 72 hours (or longer). Votes by PMC members are
> considered binding. A vote passes if there are at least three binding +1s
> and no -1's.
>


+1

Re: [DISCUSS] CEP-42: Constraints Framework

[Bernardo Botella]

Hi Ariel,

Your suggestions make sense, and I’ll be updating the CEP with the details. 
Basically:
- We have an optional name for the constraints. If the name is not provided, a 
random name is generated for a constraint:
CREATE TABLE keyspace.table (
  p1 int, 
  p2 int,
  ...,
  CONSTRAINT [name] CHECK p1 != p2
);

- Alter and Drop constraints are as follows
ALTER CONSTRAINT [name] CHECK new_condition
DROP CONSTRAINT [name]

- Describe table returns the list of constraints for a table.
- The condition of the CONSTRAINT (after the CHECK keyword) can be surrounded 
by optional parentheses to keep consistency with other databases syntax.

I will update the CEP with those details.

To Dinesh’s point, I agree that a NOT NULL constraint will be really useful. I 
can add it to the list on the CEP

Regards,
Bernardo


> On Jun 25, 2024, at 9:22 AM, Ariel Weisberg  wrote:
> 
> Hi,
> 
> I am also +1 on Doug's distinction between things that can be managed by 
> operators and things that can be managed by applications.
> 
> Some things to note about the syntax is that there are parens around the 
> condition in SQL. In your example there are multiple anonymous constraints on 
> the same column, how are anonymous constraints handled? Does the database 
> automatically generate a named constraint for them so they can be referenced 
> later? Do we allow multiple constraints on the same column and AND them 
> together?
> 
> Ariel
> 
> 
> 
> On Mon, Jun 24, 2024, at 6:43 PM, Bernardo Botella wrote:
>> Hi Ariel and Jon,
>> 
>> Let me address your question first. Yes, AND is supported in the proposal. 
>> Below you can find some examples of different constraints applied to the 
>> same column.
>> 
>> As per the LENGTH name instead of sizeOf as in the proposal, I am also not 
>> opposed to it if it is more consistent with terminology in the databases 
>> universe.
>> 
>> So, to recap, there seems to be general agreement on the usefulness of the 
>> Constraints Framework.
>> Now, from the feedback that has arrived after the voting has been called, I 
>> see there are three different proposals for syntax:
>> 
>> 1.-
>> The syntax currently described in the CEP. Example:
>> CREATE TYPE keyspace.cidr_address_ipv4 (
>>   ip_adress inet,
>>   subnet_mask int,
>>   CONSTRAINT subnet_mask > 0,
>>   CONSTRAINT subnet_mask < 32
>> )
>> 
>> 2.-
>> As Jon suggested, leaving this definitions to more specific Guardrails at 
>> table level. Example, something like:
>> column_min_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 0
>> column_max_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 32
>> 
>> 3.-
>> As Ariel suggested, having the CHECK keyword added to align consistency with 
>> SQL. Example:
>> CREATE TYPE keyspace.cidr_address_ipv4 (
>>   ip_adress inet,
>>   subnet_mask int,
>>   CONSTRAINT CHECK subnet_mask > 0,
>>   CONSTRAINT CHECK subnet_mask < 32
>> )
>> 
>> For the guardrails vs cql syntax, I think that keeping the conceptual 
>> separation that has been explored in this thread, and perfectly recapped by 
>> Doug, is closer to what we are trying to achieve with this framework. In my 
>> opinion, having them in the CQL schema definition provides those application 
>> level constraints that Doug mentions in an more accesible way than having to 
>> configure such specific guardrais.
>> 
>> For the addition of the CHECK keyword, I'm definitely not opposed to it if 
>> it helps Cassandra users coming from other databases understand concepts 
>> that were already familiar to them.
>> 
>> I hope this helps move the conversation forward,
>> Bernardo
>> 
>> 
>> 
>>> On Jun 24, 2024, at 12:17 PM, Ariel Weisberg  wrote:
>>> 
>>> Hi,
>>> 
>>> I see a vote for this has been called. I should have provided more prompt 
>>> feedback sooner.
>>> 
>>> I am a strong +1 on adding column level constraints being a good thing to 
>>> add. I'm not too concerned about row/partition/table level constraints, but 
>>> I would like to change the syntax before I would be +1 on this CEP.
>>> 
>>> It would be good to align the syntax as closely as possible to our existing 
>>> syntax, and if not that then MySQL/Postgres. For example it looks like we 
>>> don't have a string length function so maybe add `LENGTH` (consistent with 
>>> MySQL/Postgres) to also use with column level constraints.
>>> 
>>> It looks like there are generally two forms of constraint syntax, one is 
>>> expressed as part of the column definition, and the other is a named or 
>>> anonymous constraint on the table. 
>>> https://www.w3schools.com/sql/sql_check.asp
>>> 
>>> Can we align with having these column level ones as `CHECK` constraints 
>>> like in SQL, and `CONSTRAINT [constraint_name] CHECK` would be used if 
>>> creating a named or multi-column constraint?
>>> 
>>> Will column level check constraints support `AND` so that you can specify 
>>> multiple constraints on the column? I am not sure if that is supported in 
>>> other databases, but it would be

Re: [DISCUSS] CEP-42: Constraints Framework

[Josh McKenzie]

> I was referring to the name guardrail, using the same infra as guardrails
Curious if there's a subtle distinction implicit in this (or just in my 
brain...). A guardrail is something one person puts in place for someone else - 
in our case operators to users. Constraints are something inherent to the 
use-case or the abstractions, and something users are putting on themselves. 
Maybe... either that or we just named guardrails in a NIH way. /sad

That aside, if other DB's are using "constraint" I think it's the most 
user-friendly approach to use terminology they're already familiar with from 
other contexts. And we need more user-friendly. ;)

As for the infra - if we're talking plumbing inside the guts I agree. I think 
the UX definitely should be via DDL rather than the .yaml file; I don't think 
that's what you were alluding to but just figured it's worth pointing it out.

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.

On Tue, Jun 25, 2024, at 1:41 PM, Bernardo Botella wrote:
> Hi Ariel,
> 
> Your suggestions make sense, and I’ll be updating the CEP with the details. 
> Basically:
> - We have an optional name for the constraints. If the name is not provided, 
> a random name is generated for a constraint:
> CREATE TABLE keyspace.table ( p1 int, p2 int, ..., CONSTRAINT [name] CHECK p1 
> != p2 );
> 
> - Alter and Drop constraints are as follows
> ALTER CONSTRAINT [name] CHECK new_condition DROP CONSTRAINT [name]
> 
> - Describe table returns the list of constraints for a table.
> - The condition of the CONSTRAINT (after the CHECK keyword) can be surrounded 
> by optional parentheses to keep consistency with other databases syntax.
> 
> I will update the CEP with those details.
> 
> To Dinesh’s point, I agree that a NOT NULL constraint will be really useful. 
> I can add it to the list on the CEP
> 
> Regards,
> Bernardo
> 
> 
>> On Jun 25, 2024, at 9:22 AM, Ariel Weisberg  wrote:
>> 
>> Hi,
>> 
>> I am also +1 on Doug's distinction between things that can be managed by 
>> operators and things that can be managed by applications.
>> 
>> Some things to note about the syntax is that there are parens around the 
>> condition in SQL. In your example there are multiple anonymous constraints 
>> on the same column, how are anonymous constraints handled? Does the database 
>> automatically generate a named constraint for them so they can be referenced 
>> later? Do we allow multiple constraints on the same column and AND them 
>> together?
>> 
>> Ariel
>> 
>> 
>> 
>> On Mon, Jun 24, 2024, at 6:43 PM, Bernardo Botella wrote:
>>> Hi Ariel and Jon,
>>> 
>>> Let me address your question first. Yes, AND is supported in the proposal. 
>>> Below you can find some examples of different constraints applied to the 
>>> same column.
>>> 
>>> As per the LENGTH name instead of sizeOf as in the proposal, I am also not 
>>> opposed to it if it is more consistent with terminology in the databases 
>>> universe.
>>> 
>>> So, to recap, there seems to be general agreement on the usefulness of the 
>>> Constraints Framework.
>>> Now, from the feedback that has arrived after the voting has been called, I 
>>> see there are three different proposals for syntax:
>>> 
>>> 1.-
>>> The syntax currently described in the CEP. Example:
>>> CREATE TYPE keyspace.cidr_address_ipv4 (
>>>   ip_adress inet,
>>>   subnet_mask int,
>>>   CONSTRAINT subnet_mask > 0,
>>>   CONSTRAINT subnet_mask < 32
>>> )
>>> 
>>> 2.-
>>> As Jon suggested, leaving this definitions to more specific Guardrails at 
>>> table level. Example, something like:
>>> column_min_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 0
>>> column_max_int_value_size_threshold_keyspace_address_ipv4_ip_adress = 32
>>> 
>>> 3.-
>>> As Ariel suggested, having the CHECK keyword added to align consistency 
>>> with SQL. Example:
>>> CREATE TYPE keyspace.cidr_address_ipv4 (
>>>   ip_adress inet,
>>>   subnet_mask int,
>>>   CONSTRAINT CHECK subnet_mask > 0,
>>>   CONSTRAINT CHECK subnet_mask < 32
>>> )
>>> 
>>> For the guardrails vs cql syntax, I think that keeping the conceptual 
>>> separation that has been explored in this thread, and perfectly recapped by 
>>> Doug, is closer to what we are trying to achieve with this framework. In my 
>>> opinion, having them in the CQL schema definition provides those 
>>> application level constraints that Doug mentions in an more accesible way 
>>> than having to configure such specific guardrais.
>>> 
>>> For the addition of the CHECK keyword, I'm definitely not opposed to it if 
>>> it helps Cassandra users coming from other databases understand concepts 
>>> that were already familiar to them.
>>> 
>>> I hope this helps move the conversation forward,
>>> Bernardo
>>> 
>>> 
>>> 
 On Jun 24, 2024, at 12:17 PM, Ariel Weisberg  wrote:
 
 Hi,
 
 I see a vote for this has been called. I should have provided more prompt 
 feedback 

Re: [DISCUSS] CEP-42: Constraints Framework

[Dinesh Joshi]

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: [VOTE][IP CLEARANCE] GoCQL driver

[Jeff Jirsa]

+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
> asterisk have agreed to donate (copyright assign) their contributions to the
> Apache Software Foundation, signing CLAs when appropriate.

> On Jun 25, 2024, at 10:32 AM, Mick Semb Wever  wrote:
> 
>   .
>  
>> The vote will be open for 72 hours (or longer). Votes by PMC members are 
>> considered binding. A vote passes if there are at least three binding +1s 
>> and no -1's.
> 
> 
> +1
> 
> 

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Dinesh Joshi]

+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
> > asterisk have agreed to donate (copyright assign) their contributions to
> the
> > Apache Software Foundation, signing CLAs when appropriate.
>
> On Jun 25, 2024, at 10:32 AM, Mick Semb Wever  wrote:
>
>   .
>
>
>> The vote will be open for 72 hours (or longer). Votes by PMC members are
>> considered binding. A vote passes if there are at least three binding
>> +1s and no -1's.
>>
>
>
> +1
>
>
>
>

Re: [DISCUSS] CEP-42: Constraints Framework

[Abe Ratnofsky]

If we're going to introduce a feature that looks like SQL constraints, we 
should make sure it's "reasonably" compliant. In particular, we should avoid 
situations where a user creates a constraint, writes some data, then reads data 
that violates that constraint, unless they've expressed that violations on read 
would be acceptable.

For Postgres, when adding a new constraint you can specify NOT VALID to avoid 
scanning all existing relevant data[1]. If we want to avoid scan-on-DDL, this 
tradeoff needs to be made clear to a user.

As we've already discussed, constraints must deal with operations that appear 
within limits on the write path, but once reconciled on read or during 
compaction can lead to a violation. Adding to non-frozen collections is one 
example. Expecting users to understand the write path for collections feels 
unrealistic to me; I wonder if we should express in the constraint itself that 
it only applies during write.

Anything that uses "nodetool import" (including cassandra-analytics) could 
theoretically push constraint-violating mutations to a table. We could update 
import to scan table contents first, or add a flag to trust the data in 
imported SSTables and make cassandra-analytics executors aware of table-level 
constraints.

Some client implementations read the system_schema tables to build their object 
mappers, I'd like to confirm that nothing will require clients to be aware of 
these new schema constructs.

Overall, I'm supportive of the distinctions discussed between constraints and 
guardrails and like the direction this is heading; I'd just like to make sure 
the more detailed semantics aren't confusing or misleading for our users, and 
semantics are much harder to change in the future.

[1]: https://www.postgresql.org/docs/current/sql-altertable.html

Re: [DISCUSS] CEP-42: Constraints Framework

[Doug Rohrer]

On the Analytics side, as long as the CQLSSTableWriter understands and enforces 
the constraints (which it should be able to , given we provide the table 
schema) we should be good to go. We should try hard to avoid scanning the data 
on import, as the Analytics library does a bunch of things to push that kind of 
logic and CPU + I/O work off to the Spark executors that write the sstables, 
and reading the whole SSTable on import can drastically slow down that process.

I agree warning the users in docs that we don’t scan the existing data for data 
that violates constraints if the table wasn’t create with them is important, 
but I don’t think it would be feasible to do scan-on-DDL change.

Could we only support collection-level constraints on frozen lists/sets/maps, 
as that way the end user would have to be aware of the current size of the 
collection?

Doug

> On Jun 25, 2024, at 2:27 PM, Abe Ratnofsky  wrote:
> 
> If we're going to introduce a feature that looks like SQL constraints, we 
> should make sure it's "reasonably" compliant. In particular, we should avoid 
> situations where a user creates a constraint, writes some data, then reads 
> data that violates that constraint, unless they've expressed that violations 
> on read would be acceptable.
> 
> For Postgres, when adding a new constraint you can specify NOT VALID to avoid 
> scanning all existing relevant data[1]. If we want to avoid scan-on-DDL, this 
> tradeoff needs to be made clear to a user.
> 
> As we've already discussed, constraints must deal with operations that appear 
> within limits on the write path, but once reconciled on read or during 
> compaction can lead to a violation. Adding to non-frozen collections is one 
> example. Expecting users to understand the write path for collections feels 
> unrealistic to me; I wonder if we should express in the constraint itself 
> that it only applies during write.
> 
> Anything that uses "nodetool import" (including cassandra-analytics) could 
> theoretically push constraint-violating mutations to a table. We could update 
> import to scan table contents first, or add a flag to trust the data in 
> imported SSTables and make cassandra-analytics executors aware of table-level 
> constraints.
> 
> Some client implementations read the system_schema tables to build their 
> object mappers, I'd like to confirm that nothing will require clients to be 
> aware of these new schema constructs.
> 
> Overall, I'm supportive of the distinctions discussed between constraints and 
> guardrails and like the direction this is heading; I'd just like to make sure 
> the more detailed semantics aren't confusing or misleading for our users, and 
> semantics are much harder to change in the future.
> 
> [1]: https://www.postgresql.org/docs/current/sql-altertable.html
> 

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, Jun 25, 2024 at 12:30 PM Mick Semb Wever  wrote:
>
>
>
> Please vote on the acceptance of the GoCQL driver and its IP Clearance:
> https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html
>
> All consent from original authors of the donation, and tracking of collected 
> CLAs, is found in:
>  - https://github.com/gocql/gocql/issues/1751
>  - 
> https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485
> These do not require acknowledgement before the vote.
>
> The code is prepared for donation at https://github.com/gocql/gocql
>
> Once this vote passes we will request ASF Infra to move the gocql/gocql as-is 
> to apache/cassandra-gocql-driver  . The master branch and tags, with all 
> their history, will be kept.  Because consent and CLAs were not received from 
> all original authors the source files keep additional reference to their 
> earlier copyright authors and license.
>
> This will become part of the Drivers subproject, ref CEP-8: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>
> PMC members, please check carefully the IP Clearance requirements before 
> voting.
>
> The vote will be open for 72 hours (or longer). Votes by PMC members are 
> considered binding. A vote passes if there are at least three binding +1s and 
> no -1's.
>
> regards,
> Mick

Re: [DISCUSS] CEP-42: Constraints Framework

[Dinesh Joshi]

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 existing constraints changed in such a way that may render
existing data unreadable, we need a good user experience. This is what I
propose –

1. When a constraint is added or changed in such a way that existing data
could be rendered unreadable, we should warn the user.

2. Give the user a choice of whether it is ok for the data to be rendered
unreadable and an error is issued or a warning should be issued when the
read violates the constraint but data is still readable. New data going in
will meet the constraint but old data would need to be rewritten for
the application to make it compliant.

With this approach the application developer can decide what is right for
their particular use-case. In many cases the application developer may
decide to rewrite the data when they see a warning.


On Tue, Jun 25, 2024 at 12:46 PM Abe Ratnofsky  wrote:

> If we're going to introduce a feature that looks like SQL constraints, we
> should make sure it's "reasonably" compliant. In particular, we should
> avoid situations where a user creates a constraint, writes some data, then
> reads data that violates that constraint, unless they've expressed that
> violations on read would be acceptable.
>
> For Postgres, when adding a new constraint you can specify NOT VALID to
> avoid scanning all existing relevant data[1]. If we want to avoid
> scan-on-DDL, this tradeoff needs to be made clear to a user.
>
> As we've already discussed, constraints must deal with operations that
> appear within limits on the write path, but once reconciled on read or
> during compaction can lead to a violation. Adding to non-frozen collections
> is one example. Expecting users to understand the write path for
> collections feels unrealistic to me; I wonder if we should express in the
> constraint itself that it only applies during write.
>
> Anything that uses "nodetool import" (including cassandra-analytics) could
> theoretically push constraint-violating mutations to a table. We could
> update import to scan table contents first, or add a flag to trust the data
> in imported SSTables and make cassandra-analytics executors aware of
> table-level constraints.
>
> Some client implementations read the system_schema tables to build their
> object mappers, I'd like to confirm that nothing will require clients to be
> aware of these new schema constructs.
>
> Overall, I'm supportive of the distinctions discussed between constraints
> and guardrails and like the direction this is heading; I'd just like to
> make sure the more detailed semantics aren't confusing or misleading for
> our users, and semantics are much harder to change in the future.
>
> [1]: https://www.postgresql.org/docs/current/sql-altertable.html
>
>

Re: [DISCUSS] CEP-42: Constraints Framework

[Štefan Miklošovič]

I wonder how often it is that users will apply the constraints on tables
with data while they know their data is probably not compliant with the
constraint configuration. I humbly think that people are aware of this in
advance and what usually happens is that there is some kind of a job which
consolidates the data (or migrates them to a new table) before admins put a
"lid" on that so moving forward nobody puts there anything which would
violate it.

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 Dinesh Joshi  wrote:

> 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 existing constraints changed in such a way that may render
> existing data unreadable, we need a good user experience. This is what I
> propose –
>
> 1. When a constraint is added or changed in such a way that existing data
> could be rendered unreadable, we should warn the user.
>
> 2. Give the user a choice of whether it is ok for the data to be rendered
> unreadable and an error is issued or a warning should be issued when the
> read violates the constraint but data is still readable. New data going in
> will meet the constraint but old data would need to be rewritten for
> the application to make it compliant.
>
> With this approach the application developer can decide what is right for
> their particular use-case. In many cases the application developer may
> decide to rewrite the data when they see a warning.
>
>
> On Tue, Jun 25, 2024 at 12:46 PM Abe Ratnofsky  wrote:
>
>> If we're going to introduce a feature that looks like SQL constraints, we
>> should make sure it's "reasonably" compliant. In particular, we should
>> avoid situations where a user creates a constraint, writes some data, then
>> reads data that violates that constraint, unless they've expressed that
>> violations on read would be acceptable.
>>
>> For Postgres, when adding a new constraint you can specify NOT VALID to
>> avoid scanning all existing relevant data[1]. If we want to avoid
>> scan-on-DDL, this tradeoff needs to be made clear to a user.
>>
>> As we've already discussed, constraints must deal with operations that
>> appear within limits on the write path, but once reconciled on read or
>> during compaction can lead to a violation. Adding to non-frozen collections
>> is one example. Expecting users to understand the write path for
>> collections feels unrealistic to me; I wonder if we should express in the
>> constraint itself that it only applies during write.
>>
>> Anything that uses "nodetool import" (including cassandra-analytics)
>> could theoretically push constraint-violating mutations to a table. We
>> could update import to scan table contents first, or add a flag to trust
>> the data in imported SSTables and make cassandra-analytics executors aware
>> of table-level constraints.
>>
>> Some client implementations read the system_schema tables to build their
>> object mappers, I'd like to confirm that nothing will require clients to be
>> aware of these new schema constructs.
>>
>> Overall, I'm supportive of the distinctions discussed between constraints
>> and guardrails and like the direction this is heading; I'd just like to
>> make sure the more detailed semantics aren't confusing or misleading for
>> our users, and semantics are much harder to change in the future.
>>
>> [1]: https://www.postgresql.org/docs/current/sql-altertable.html
>>
>>

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Josh McKenzie]

+1; appreciate you driving this Mick and everyone rallying.

On Tue, Jun 25, 2024, at 1:32 PM, Mick Semb Wever wrote:
>   .
>  
>> The vote will be open for 72 hours (or longer). Votes by PMC members are 
>> considered binding. A vote passes if there are at least three binding +1s 
>> and no -1's.
> 
> 
> +1
> 
> 

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Michael Shuler]

+1

Kind regards,
Michael

On 6/25/24 12:29, Mick Semb Wever wrote:


Please vote on the acceptance of the GoCQL driver and its IP Clearance:
https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html 



All consent from original authors of the donation, and tracking of 
collected CLAs, is found in:
  - https://github.com/gocql/gocql/issues/1751 

  - 
https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485 

These do not require acknowledgement before thevote.

The code is prepared for donation at https://github.com/gocql/gocql 



Once thisvotepasses we will request ASF Infra to move the gocql/gocql 
as-is to apache/cassandra-gocql-driver  . The master branch and tags, 
with all their history, will be kept.  Because consent and CLAs were not 
received from all original authors the source files keep additional 
reference to their earlier copyright authors and license.


This will become part of the Drivers subproject, ref CEP-8: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation 


PMC members, please check carefully the IP Clearance requirements 
beforevoting.


Thevotewill be open for 72 hours (or longer).Votesby PMC members are 
considered binding. Avotepasses if there are at least three binding +1s 
and no -1's.


regards,
Mick

Re: [DISCUSS] CEP-42: Constraints Framework

[Yifan Cai]

>
> - Alter and Drop constraints are as follows
> ALTER CONSTRAINT [name] CHECK new_condition DROP CONSTRAINT [name]
>

I think you mean the following syntax to modify existing constraints, since
constraints are part of the table definition.
ALTER TABLE [keyspace_name.]table_name ALTER CONSTRAINT [constraint_name]
CHECK check_expression

Dinesh's proposal to check on read is a good addition. I think it is
*optional* and should be enabled/disabled w/ configuration. The extra check
may not be desirable in some circumstances, e.g. the use cases do not ever
change the constraints and do not have other write data other than CQL.
Since the original CEP defines that the constraints are applied at the
write time, we need to update the CEP if we decide to include the check on
read.

- Yifan


On Tue, Jun 25, 2024 at 1:13 PM Štefan Miklošovič 
wrote:

> I wonder how often it is that users will apply the constraints on tables
> with data while they know their data is probably not compliant with the
> constraint configuration. I humbly think that people are aware of this in
> advance and what usually happens is that there is some kind of a job which
> consolidates the data (or migrates them to a new table) before admins put a
> "lid" on that so moving forward nobody puts there anything which would
> violate it.
>
> 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 Dinesh Joshi  wrote:
>
>> 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 existing constraints changed in such a way that may render
>> existing data unreadable, we need a good user experience. This is what I
>> propose –
>>
>> 1. When a constraint is added or changed in such a way that existing data
>> could be rendered unreadable, we should warn the user.
>>
>> 2. Give the user a choice of whether it is ok for the data to be rendered
>> unreadable and an error is issued or a warning should be issued when the
>> read violates the constraint but data is still readable. New data going in
>> will meet the constraint but old data would need to be rewritten for
>> the application to make it compliant.
>>
>> With this approach the application developer can decide what is right for
>> their particular use-case. In many cases the application developer may
>> decide to rewrite the data when they see a warning.
>>
>>
>> On Tue, Jun 25, 2024 at 12:46 PM Abe Ratnofsky  wrote:
>>
>>> If we're going to introduce a feature that looks like SQL constraints,
>>> we should make sure it's "reasonably" compliant. In particular, we should
>>> avoid situations where a user creates a constraint, writes some data, then
>>> reads data that violates that constraint, unless they've expressed that
>>> violations on read would be acceptable.
>>>
>>> For Postgres, when adding a new constraint you can specify NOT VALID to
>>> avoid scanning all existing relevant data[1]. If we want to avoid
>>> scan-on-DDL, this tradeoff needs to be made clear to a user.
>>>
>>> As we've already discussed, constraints must deal with operations that
>>> appear within limits on the write path, but once reconciled on read or
>>> during compaction can lead to a violation. Adding to non-frozen collections
>>> is one example. Expecting users to understand the write path for
>>> collections feels unrealistic to me; I wonder if we should express in the
>>> constraint itself that it only applies during write.
>>>
>>> Anything that uses "nodetool import" (including cassandra-analytics)
>>> could theoretically push constraint-violating mutations to a table. We
>>> could update import to scan table contents first, or add a flag to trust
>>> the data in imported SSTables and make cassandra-analytics executors aware
>>> of table-level constraints.
>>>
>>> Some client implementations read the system_schema tables to build their
>>> object mappers, I'd like to confirm that nothing will require clients to be
>>> aware of these new schema constructs.
>>>
>>> Overall, I'm supportive of the distinctions discussed between
>>> constraints and guardrails and like the direction this is heading; I'd just
>>> like to make sure the more detailed semantics aren't confusing or
>>> misleading for our users, and semantics are much harder to change in the
>>> future.
>>>
>>> [1]: https://www.postgresql.org/docs/current/sql-altertable.html
>>>
>>>

Re: [VOTE][IP CLEARANCE] GoCQL driver

[J. D. Jordan]

+1 nb. Good to see this heavily used driver get continued development in the 
project.

> On Jun 25, 2024, at 5:29 PM, Michael Shuler  wrote:
> 
> +1
> 
> Kind regards,
> Michael
> 
>> On 6/25/24 12:29, Mick Semb Wever wrote:
>> Please vote on the acceptance of the GoCQL driver and its IP Clearance:
>> https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html 
>> 
>> All consent from original authors of the donation, and tracking of collected 
>> CLAs, is found in:
>>  - https://github.com/gocql/gocql/issues/1751 
>> 
>>  - 
>> https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485
>>  
>> 
>> These do not require acknowledgement before thevote.
>> The code is prepared for donation at https://github.com/gocql/gocql 
>> 
>> Once thisvotepasses we will request ASF Infra to move the gocql/gocql as-is 
>> to apache/cassandra-gocql-driver  . The master branch and tags, with all 
>> their history, will be kept.  Because consent and CLAs were not received 
>> from all original authors the source files keep additional reference to 
>> their earlier copyright authors and license.
>> This will become part of the Drivers subproject, ref CEP-8: 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>>  
>> 
>> PMC members, please check carefully the IP Clearance requirements 
>> beforevoting.
>> Thevotewill be open for 72 hours (or longer).Votesby PMC members are 
>> considered binding. Avotepasses if there are at least three binding +1s and 
>> no -1's.
>> regards,
>> Mick

Re: [VOTE] Release Apache Cassandra 5.0-rc1

[Jon Haddad]

5.0 is a massive milestone.  A huge thank you to everyone that's invested
their time into the release.  I've done a lot of testing, benchmarking, and
tire kicking and it's truly mind blowing how much has gone into 5.0 and how
great it is for the community.

I am a bit concerned that CASSANDRA-19668, which I found in 4.1, will also
affect 5.0.  This is a pretty serious bug, where using Paxos v2 + off heap
memtables can cause a SIGSEV process crash.  I've seen this happen about a
dozen times with a client over the last 3 months.  Since the new trie
memtables rely on off heap, and both Trie memtables & Paxos V2 is so
compelling (esp for multi-dc users), I think there's a good chance that
we'll be making an already bad problem even worse, for folks that use LWT.

Unfortunately, until next week I'm unable to put any time into this; I'm on
vacation with my family.  I wish I had been able to confirm and raise this
issue as a 5.0 blocker sooner, but I've deliberately tried to keep work
stuff out of my mind.   Since I'm not 100% sure if this affects 5.0, I'm
not blocking the RC, but I don't feel comfortable putting a +1 on a release
that I'm at least 80% certain contains a process-crashing bug.

I have a simple 4.1 patch in CASSANDRA-19668, but I haven't landed a commit
in several years and I have zero recollection of the entire process of
getting it in, nor have I spent any time writing unit or dtests in the C*
repo.  I ran a test of 160MM LWTs over several hours with my 4.1 branch and
didn't hit any issues, but my client ran for weeks without hitting it so
it's hard to say if I've actually addressed the problem, as it's a rare
race condition.  Fwiw, I don't need to be the one to
handle CASSANDRA-19668, so if someone wants to address it before me, please
feel free.  It will likely take me a lot longer to deal with than someone
more involved with the process, and I'd want 2 sets of eyes on it anyways
given what I already mentioned previously about committing and testing.

Jon


On Tue, Jun 25, 2024 at 2:53 PM Mick Semb Wever  wrote:

>
>
> .
>
> Proposing the test build of Cassandra 5.0-rc1 for release.
>>
>> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
>> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/
>>
>
>
> The three green CI runs for this are
> -
> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-2
> -
> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-3
> -
> https://app.circleci.com/pipelines/github/driftx/cassandra?branch=5.0-rc1-4
>
>
>

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Jon Haddad]

+1.

On Wed, Jun 26, 2024 at 1:50 AM J. D. Jordan 
wrote:

> +1 nb. Good to see this heavily used driver get continued development in
> the project.
>
> > On Jun 25, 2024, at 5:29 PM, Michael Shuler 
> wrote:
> >
> > +1
> >
> > Kind regards,
> > Michael
> >
> >> On 6/25/24 12:29, Mick Semb Wever wrote:
> >> Please vote on the acceptance of the GoCQL driver and its IP Clearance:
> >> https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html <
> https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html>
> >> All consent from original authors of the donation, and tracking of
> collected CLAs, is found in:
> >>  - https://github.com/gocql/gocql/issues/1751 <
> https://github.com/gocql/gocql/issues/1751>
> >>  -
> https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485
> <
> https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485
> >
> >> These do not require acknowledgement before thevote.
> >> The code is prepared for donation at https://github.com/gocql/gocql <
> https://github.com/gocql/gocql>
> >> Once thisvotepasses we will request ASF Infra to move the gocql/gocql
> as-is to apache/cassandra-gocql-driver  . The master branch and tags, with
> all their history, will be kept.  Because consent and CLAs were not
> received from all original authors the source files keep additional
> reference to their earlier copyright authors and license.
> >> This will become part of the Drivers subproject, ref CEP-8:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
> <
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
> >
> >> PMC members, please check carefully the IP Clearance requirements
> beforevoting.
> >> Thevotewill be open for 72 hours (or longer).Votesby PMC members are
> considered binding. Avotepasses if there are at least three binding +1s and
> no -1's.
> >> regards,
> >> Mick
>

Re: [VOTE] Release Apache Cassandra 5.0-rc1

[Jeff Jirsa]

+1



> On Jun 25, 2024, at 5:04 AM, Mick Semb Wever  wrote:
> 
> 
> 
> Proposing the test build of Cassandra 5.0-rc1 for release.
> 
> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1336/org/apache/cassandra/cassandra-all/5.0-rc1/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-rc1/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/NEWS.txt

Re: [VOTE][IP CLEARANCE] GoCQL driver

[Ekaterina Dimitrova]

+1

On Wed, 26 Jun 2024 at 6:14, Jon Haddad  wrote:

> +1.
>
> On Wed, Jun 26, 2024 at 1:50 AM J. D. Jordan 
> wrote:
>
>> +1 nb. Good to see this heavily used driver get continued development in
>> the project.
>>
>> > On Jun 25, 2024, at 5:29 PM, Michael Shuler 
>> wrote:
>> >
>> > +1
>> >
>> > Kind regards,
>> > Michael
>> >
>> >> On 6/25/24 12:29, Mick Semb Wever wrote:
>> >> Please vote on the acceptance of the GoCQL driver and its IP Clearance:
>> >> https://incubator.apache.org/ip-clearance/cassandra-gocql-driver.html
>> 
>> >> All consent from original authors of the donation, and tracking of
>> collected CLAs, is found in:
>> >>  - https://github.com/gocql/gocql/issues/1751 <
>> https://github.com/gocql/gocql/issues/1751>
>> >>  -
>> https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485
>> <
>> https://cwiki.apache.org/confluence/pages/worddav/preview.action?fileName=GoCQL+ASF+CLA+collection.xlsx&pageId=225152485
>> >
>> >> These do not require acknowledgement before thevote.
>> >> The code is prepared for donation at https://github.com/gocql/gocql <
>> https://github.com/gocql/gocql>
>> >> Once thisvotepasses we will request ASF Infra to move the gocql/gocql
>> as-is to apache/cassandra-gocql-driver  . The master branch and tags, with
>> all their history, will be kept.  Because consent and CLAs were not
>> received from all original authors the source files keep additional
>> reference to their earlier copyright authors and license.
>> >> This will become part of the Drivers subproject, ref CEP-8:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>> <
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>> >
>> >> PMC members, please check carefully the IP Clearance requirements
>> beforevoting.
>> >> Thevotewill be open for 72 hours (or longer).Votesby PMC members are
>> considered binding. Avotepasses if there are at least three binding +1s and
>> no -1's.
>> >> regards,
>> >> Mick
>>
>