Re: [VOTE] Release Apache Cassandra Java Driver 4.19.0

+1 Verified sigs and artifact coordinates. On Tue, Feb 11, 2025 at 12:30 PM Brandon Williams wrote: > +1 > > Checked sha/sig, maven artifacts, built on j8. > > Kind Regards, > Brandon > > On Thu, Feb 6, 2025 at 4:34 PM Bret McGuire > wrote: > > > >Greetings all! I’m proposing the test buil

Re: [VOTE] Release Apache Cassandra Java Driver 4.19.0

+1 Checked sha/sig, maven artifacts, built on j8. Kind Regards, Brandon On Thu, Feb 6, 2025 at 4:34 PM Bret McGuire wrote: > >Greetings all! I’m proposing the test build of Cassandra Java Driver > 4.19.0 for release. > > > sha1: 46444eaabdbd23e9231123198536d070e99aca27 > > Git: https://gi

Re: CVE-2025-23015: Apache Cassandra: User with MODIFY permission on ALL KEYSPACES can escalate privileges to superuser via unsafe actions

A performance regression was detected in the security releases 3.0.31 [1] and 3.11.18 [2]. Users affected by this vulnerability are recommended to upgrade to versions 3.0.32 and 3.11.19 instead. Remaining versions are unaffected. [1] - https://lists.apache.org/thread/yprngr9cmp9c43m1c56thv1v0v6y5

Re: [VOTE] Release Apache Cassandra Java Driver 4.19.0

+1 (nb) Tried a few things * Added the maven repository to a project and did some quick sanity testing w/ 4.19.0 (java-driver-core and java-driver-core-shaded) * signature matches Bret's from KEYS and also verified checksums from subversion * built the

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

We have consensus then. Let’s ditch the non strict version, and rename the STRICTLY_NOT_NULL to NOT_NULL. Thanks everyone! Bernardo > On Feb 10, 2025, at 8:58 AM, Štefan Miklošovič wrote: > > I agree. > > The only reason would be purely practical: if a user has a table consisting > of 1000 c

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

I agree. The only reason would be purely practical: if a user has a table consisting of 1000 columns not being null and a user wants to modify 1 column only, then a user would be forced to specify the remaining 999 columns just for the sake of it. But in this case, I think it would be more practi

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

While LOOSE_NOT_NULL might improve the clarity a bit, what is the value of such constraint provides to users? It still permits null. Meanwhile, it is easier to check the nullness of the bound values on the application side. IMO, what benefits users is a way to ensure no null value can exist for t

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

To recap, The sentiment I am getting is that NOT_NULL allowing null values is too confusing. Nice, that’s why we started the thread. As an alternative, instead of ditching the loose not null constraint, I propose we change the “default” behavior. From my initial proposal, I suggest renaming th

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

On Mon, Feb 10, 2025 at 5:20 PM Dinesh Joshi wrote: > 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 t

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

Rereading this: I do think any implementation of NOT NULL that has a way to let NULL in is bad. So I would be -1 on the proposal here that lets through INSERTs that don’t specify the column and also: " requiring that for INSERT, letting UPDATE be “user beware” - and you -1 it as well, that looks

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] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

That looks like our STRICT_NOT_NULL would be "NOT NULL", so we would collapse the second, stricter, case into the default one, if I understand correctly. Would you mind telling us what you would actually +1? You have -1 both 1) and 2). On Mon, Feb 10, 2025 at 5:00 PM Jeremiah Jordan wrote: > Ha

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

Having thought about this in the past, some options that have come up in those discussions were: 1. Constraints forcing users to always specify a value for a given column or all columns. Only allow NOT NULL for columns with such a constraint applied. 2. Similar to the above but only

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

The reason it looks "strange" is that we are dealing with a completely different concept of "NOT NULL" from e.g. MySQL. In MySQL (as I just tried here locally so I describe what I saw), a user has to, by default, specify all columns in the table for an insert. There is, by default, nothing like wh

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

I will create a Jira to keep track of that “NO VERIFY” suggestion. For this thread, I’d like to stick to the actual proposal for both NOT_NULL and STRICTLY_NOT_NULL constraints Stefan and I are adding on the patch. > On Feb 10, 2025, at 7:18 AM, Benedict wrote: > > Thanks. While I agree we sh

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

Thanks. While I agree we shouldn’t be applying these constraints post hoc on read or compaction, I think we need to make clear to the user whether we are validating a new constraint before accepting it for alter table. Which is to say I think alter table should require something like “NO VERIFY” or

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

Hi. These was a topic we discussed during the ML thread: https://lists.apache.org/thread/xc2phmxgsc7t3y9b23079vbflrhyyywj Here was one of my answers on that: https://lists.apache.org/thread/76olqf6225noygxcclsrs56ngnlmcvxv It was also specified in the CEP (https://cwiki.apache.org/confluence/d

Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

This is counterintuitive to me. The constraint should be applied to the table, not to the update. NOT NULL should imply a value is always specified. How are you handling this for tables that already exist? Can we alter table to add constraints, and if so what are the semantics? > On 10 Feb 2025

[DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint

Hi everyone, Stefan Miklosovic and I have been working on a NOT_NULL (https://github.com/apache/cassandra/pull/3867) constraint to be added to the constraints tool belt, and a really interesting conversation came up. First, as a problem statement, let's consider this: -

Re: 【DISCUSS】What is the current status of triggers in Cassandra ?

Hi Stefan , Yes ,you are right, That is why I send the second email stating that we are not going to support cloning triggers in CREATE TABLE LIKE . Štefan Miklošovič 于2025年2月10日周一 18:12写道： > Hi Maxwell, > > even the issues mentioned in CASSANDRA-20287 are fixed, I still do not > think we should

Re: 【DISCUSS】What is the current status of triggers in Cassandra ?

Hi Maxwell, even the issues mentioned in CASSANDRA-20287 are fixed, I still do not think we should support the copying of triggers. Reasons I think we should not support that are: 1) According to this comment (1) Triggers API is considered beta and can change. Unless we promote trigger's API out

Re: 【DISCUSS】What is the current status of triggers in Cassandra ?

Referring to the opinions of most people, we ignore the cloning of triggers just for the CREATE TABLE LIKE feature. guo Maxwell 于2025年2月10日周一 16:39写道： > Then we don’t support trigger until CASSANDRA-20287 is fixed, and this > rule applies to custom index , too. right ? > > > Sam Tunnicliffe 于20

Re: 【DISCUSS】What is the current status of triggers in Cassandra ?

Then we don’t support trigger until CASSANDRA-20287 is fixed, and this rule applies to custom index , too. right ? Sam Tunnicliffe 于2025年2月5日周三 01:24写道： > This is really a bug with the current implementation of > CreateTriggerStatement and I've filed CASSANDRA-20287 to address it. > > Thanks, >