Hi Jyothsna,
Thank you for this proposal.
While reading it, various questions / points came to my mind:
1) In your examples, Description can take an argument - a comment
describing an element of a schema. However, I can imagine that not all
annotations need to have an argument like that. E.g. @P
The Cassandra team is pleased to announce the release of Apache Cassandra
version 5.0.5.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
https://cassandra.apache.org/
Downloads of source a
The vote passed with 3 binding +1s and no vetoes.
thread or get on a quick call and bring back the summary
> back to this list. Happy to organize a call if y'all are interested.
>
>
> On Fri, Aug 1, 2025 at 9:07 AM Štefan Miklošovič
> wrote:
>
>> Looking into my prototype (I think it is not doing anything yet, just
>
t; w/o dictionary. Unfortunately, the work went to backlog. I can pick it up
> again if there is a demand for the feature.
> There are some discussions in the Jira that Stefan linked. (thanks Stefan!)
>
> - Yifan
>
> ------
> *From:* Štefan Miklošovič
> *Sent
There is already a ticket for this
https://issues.apache.org/jira/browse/CASSANDRA-17021
I would love to see this in action, I was investigating this a few years
ago when ZSTD landed for the first time in 4.0 I think, I was discussing
that with Yifan, I think, if my memory serves me well, but, as
+1
On Thu, Jul 31, 2025 at 2:58 PM Štefan Miklošovič
wrote:
> Proposing the test build of Cassandra 5.0.5 for release.
>
> sha1: c8abc9f3e1bb46bc4d699c3a167e43df62b9bec8
> Git: https://github.com/apache/cassandra/tree/5.0.5-tentative
> Maven Artifacts:
> https://repository.
Proposing the test build of Cassandra 5.0.5 for release.
sha1: c8abc9f3e1bb46bc4d699c3a167e43df62b9bec8
Git: https://github.com/apache/cassandra/tree/5.0.5-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1408/org/apache/cassandra/cassandra-all/5.0.5
-tentative/CHANGES.txt
[2]: NEWS.txt:
https://github.com/apache/cassandra/blob/5.0.5-tentative/NEWS.txt
On Wed, Jul 30, 2025 at 10:16 PM Štefan Miklošovič
wrote:
> Yeah I get that from the perspective of users not running on Debian etc.
> However we support Debian and RHEL / building packages fo
x27;s a
> slippery slope and it doesn't really seem right to delay 5.0.5 for
> non-Debian users who might want some fix that 5.0.5 has sooner.
>
> Kind Regards,
> Brandon
>
> On Wed, Jul 30, 2025 at 3:03 PM Štefan Miklošovič
> wrote:
> >
> > There is Debian 13
the corner and 5.0.4 was released so long ago anyway ...
Thoughts?
On Wed, Jul 30, 2025 at 1:49 PM Štefan Miklošovič
wrote:
> During evaluation / testing what was staged, I have identified (1) to be a
> blocker as source artifacts are not buildable because of that.
>
> We need to
Tue, Jul 29, 2025 at 12:38 PM Štefan Miklošovič
wrote:
> The test build of Cassandra 5.0.5 is available.
>
> sha1: 090a773e1b70bdd4722a942463fb299c08048ca8
> Git: https://github.com/apache/cassandra/tree/5.0.5-tentative
> Maven Artifacts:
> https://repository.apache.org/co
The test build of Cassandra 5.0.5 is available.
sha1: 090a773e1b70bdd4722a942463fb299c08048ca8
Git: https://github.com/apache/cassandra/tree/5.0.5-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1407/org/apache/cassandra/cassandra-all/5.0.5/
The So
ables will be done. Also, I agree with all points made around transition
> time on the ticket.
>
> I support the addition of those nodetool get/set commands. 4.1 and 5.0
> will still be around for some time.
>
> Best regards,
> Ekaterina
>
> On Thu, 10 Jul 2025 at 7:23, Brando
know if you encounter any issues, and I will fix them asap.
>
> On Tue, 13 May 2025 at 11:17, Dmitry Konstantinov
> wrote:
> >
> > Hi Maxim, I will take a look too.
> >
> > Regards,
> > Dmitry
> >
> > On Tue, 13 May 2025 at 08:59, Štefan Miklošovič
>
+1
On Tue, Jul 22, 2025 at 5:03 AM Bernardo Botella <
conta...@bernardobotella.com> wrote:
> Proposing the test build of Cassandra Analytics 0.1.0 for release.
>
> sha1: 6e1d5257a8d6c910a42751475612145533ae3b1d
> Git: https://github.com/apache/cassandra-analytics/tree/0.1.0-tentative
> Maven Arti
og to get around to that; I think it's
> pretty well documented here
> <https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Managers+Onboarding>
> in
> case anyone else has the cycles right now.
>
> On Fri, Jul 18, 2025, at 2:01 AM, Štefan Miklošovič wrote:
>
he/cassandra/cassandra-bridge_spark3_2.13/0.1.0/
>
>
> (Note the number went to 1406)
>
> For your question, the artifacts are generated with different versions of
> Scala, hence the different names.
>
> Bernardo
>
> On Jul 17, 2025, at 2:51 AM, Štefan Miklošovič
> w
I was planning to stage it after 19552 and Paulo's 19902. Do you know the
drill? Feel free to do that if you want. Seems like it is just me, Brandon
and Michael who exercises the releases, we should make the group of people
able to do that more wider but no problem staging it myself if you want ...
Thank you for the next round of this!
I am trying it again and I see
https://repository.apache.org/content/repositories/orgapachecassandra-1405/org/apache/cassandra/cassandra-analytics-sidecar-client/0.1.0/cassandra-analytics-sidecar-client-0.1.0.pom
This has
org.apache.cassandra
cassandra-brid
There is (1) which attempts to add guardrails get/set configuration to
nodetool.
When first encountered, I suggested that we might do a CQL vtable approach
instead.
This is still not done and Paulo asked if the nodetool approach could not
be still added to 5.0 (2)
The justification is that we ha
+1
On Thu, Jul 3, 2025 at 6:07 PM João Reis wrote:
> Hey folks,
>
> I’m proposing the Apache Cassandra GoCQL Driver 2.0.0-rc1 for release (2nd
> attempt).
>
> sha1: 722707e3df954a43c5aa708de8569fff38f1d5a7
> git:
> https://github.com/apache/cassandra-gocql-driver/tree/v2.0.0-rc1-tentative
>
> Th
The vote has not passed due to found critical bug [1]
https://issues.apache.org/jira/browse/CASSGO-82
-client_spark3_2.12
0.1.0
but it is nowhere to find.
Regards
On Wed, Jul 2, 2025 at 3:19 PM Štefan Miklošovič
wrote:
> I am developing a project against analytics dependencies, I removed
> everything locally from ~/.m2 and I pointed my Maven project to use staged
> repositor
I am developing a project against analytics dependencies, I removed
everything locally from ~/.m2 and I pointed my Maven project to use staged
repository
https://repository.apache.org/content/repositories/orgapachecassandra-1403
I am missing:
1)
org.apache.cassandra:cassandra-analytics-sidecar-c
+1
On Mon, Jun 30, 2025 at 2:02 PM João Reis wrote:
> Hey folks,
>
> I’m proposing the Apache Cassandra GoCQL Driver 2.0.0-rc1 for release.
>
> sha1: a9bfe80d8e6fad320c0737c9484056e9de7bef74
> git:
> https://github.com/apache/cassandra-gocql-driver/tree/v2.0.0-rc1-tentative
>
> The Source releas
I haven't looked at what was staged too closely but I noticed that the
links Bernardo posted in this VOTE thread were actually leading nowhere.
There should be just jars etc. behind them and so on, same kind of stuff
when we stage Cassandra.
I am not sure if people were aware of it or it went unno
+1
On Fri, Jun 13, 2025 at 1:58 PM Josh McKenzie wrote:
> [DISCUSS] thread:
> https://lists.apache.org/thread/vr7j2ob92k6fbcwvlfo60l3scylzdbft
>
> Text to vote on:
>
> --
> *[New LTS JDK Adoption]*
>
>- When
Hi Josh,
One observation, you wrote:
"Backports from trunk to older branches that utilize the latest language
level would need to be refactored to work on older branches."
This is interesting. There are two possibilities
1) As you said, in trunk, we would go with the latest language level
featu
Updated 5.0 and trunk branches to reflect this under CASSANDRA-20681. Let
us know if this is, for some reason, not enough and you want to propagate
this information further.
On Wed, May 28, 2025 at 11:32 PM Jeremiah Jordan
wrote:
> +1
>
> On May 28, 2025 at 4:28:22 PM, Mick Semb Wever wrote:
>
I would like to discuss (1). The problem is that we sometimes see that when
a metric like EstimatedPartitionCount is called while a compaction is in
progress, it might spin endlessly until compaction finishes.
The reason it spins is that (summarized here (2)) when compaction evaluates
some SSTable
+1
On Thu, May 22, 2025 at 2:17 PM Brandon Williams
wrote:
> Proposing the test build of Cassandra 4.0.18 for release.
>
> sha1: 422b8a6cbd6cae2aa8551e668e3a9c6dc92858c4
> Git: https://github.com/apache/cassandra/tree/4.0.18-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/
Hey,
I mapped what command line parser styles we use across the project while
dealing with some ticket (20448) and it is mixed like this, I am talking
about stuff we use in commons-cli for Gnu and Posix parsers:
GnuParser
StandaloneSplitter
BulkLoader (aka sstableloader)
HashPassword
GenerateTok
for N token-splits for a table. However,
> CLEANUP_MSG is only invoked once for a table, complicating the cleanup of
> the snapshots.
>
> Jaydeep
>
>
>
> On Tue, May 13, 2025 at 8:56 AM Štefan Miklošovič
> wrote:
>
>> That true / false for "force"
true or false? I assumed this
> was the force flag in repair (as these are repair snapshots) but sounds
> like that isn’t the case?
>
> Sent from my iPhone
>
> On May 12, 2025, at 11:58 PM, Štefan Miklošovič
> wrote:
>
>
> David,
>
> that "force" y
Hi Maxim,
I took yet another look after my initial review some time ago and I still
do not see any issues with it.
I appreciate that by default it behaves exactly the same way as before and
one has to just flip a switch (env property / system property) to start to
use another layout.
Arguments /
Congratulations!
On Mon, May 12, 2025 at 6:48 PM Alex Petrov wrote:
> Hello folks of the dev list,
>
> The Apache Cassandra PMC is very glad to announce that Abe Ratnofsky has
> accepted our invitation to become a committer!
>
> Abe has been actively contributing to Cassandra itself, made outsta
ing a bug (aka worthy of a back
> port)…. I know most users do parallel repair (default) so this snapshot
> logic doesn’t impact most users, but its also why its been so long before
> this issue got noticed… so coverage around snapshots currently isn’t the
> best.
>
> Sorry for this
+1, great stuff, looking forward to bring it out of experimental
On Mon, May 12, 2025 at 4:27 PM Ariel Weisberg wrote:
> Hi dev@,
>
> I would like to start the voting for CEP-46: Finish Transient
> Replication/Witnesses
>
> Proposal:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pa
Hello,
I am looking for advice for (1). There is quite a quality archaeology to go
through. I have asked around already (thanks for that!) but nobody seems to
ultimately remember / tell what it is for.
There is (2). "force" can be true / false. When true, then it will not
check if a snapshot exis
I don't see it necessary to port Gradle stuff to Ant. I have noticed zero
problems with it after CEP-15 merge. Basically a non-event.
It just looks strange that we have Ant + Maven poms / resolver wired into
it + submodule on Gradle. I mean ... wow. There is nothing wrong per se but
... strange. O
It is not installed when it is present on the computer already, it should
take that instead.
If we treat Go the same way as Python then we might drop its installation.
It is there for convenience mostly. We also do not install Python so ...
On Thu, Apr 24, 2025 at 12:24 PM Brandon Williams wrote
Hi Alex, all
The way I use it is that I have this in build.properties (just copy
build.properties.default in repo) and change the content.
build.properties file is in .gitignore and I think it is the most idiomatic
way to do this kind of stuff.
$ cat build.properties
ant.gen-doc.skip=true
ant.no
Hi Doug,
I would love to help you with some of that. Spark 4.0 support seems
appealing to me. Let me check with my "backend" if there is any capacity
doing so and connecting privately to hash out the details.
Regards
On Tue, Apr 22, 2025 at 7:53 PM Doug Rohrer wrote:
> Hello folks,
>
> As many
I can definitely see a logic in not removing. When I saw deprecated
annotations for the first time after I mapped where we deprecated it, my
initial desire was to invent some logic to remove it all after some period
of time but that is not a good idea after all.
We had a thread about this here (1)
l mutations to have price and
>>>> name, as we wouldn’t know the value of name in the following query
>>>>
>>>> INSERT INTO tbl (pk, ck, price) VALUES (0, 0, 0);
>>>>
>>>> So, do we put such a limitation on users and force them to define
&
on everyone else does this the
>> same is it is part of the standard. So, I am more than happy to stick to
>> the CHECK qualifier for all of our unique extensions, but for NOT NULL we
>> should absolutely follow the SQL standard, and for the same reason we
>> should use the fie
the name of a branch
of that PR?). Anyway, I would expect that the same is done when a JIRA is
closed - that it would go over the links of PRs and close them. When it can
work one way, why cannot it work the other way around as well?
> :D
>
> On Mon, Apr 14, 2025, at 8:27 AM, Mick Sem
gt;>> does not seem very obvious, but it's also a bit inconvenient.
>>>
>>
>>>
>>> Since Apache INFRA already links github PRs to the appropriate JIRA, it
>>> would probably not be very hard to have the PR be closed when the JIRA is
>>>
CHECK keyword, specifying that they are a constraint that
> will be checked (aka, row value will be validated against whatever
> function). That’s easy to identify, and it’s conceptually easy to
> understand the limitations it comes with (as opposed to the JSON example
> menti
As Yifan already said, "check" is not a reserved word now and its usage
does not collide with anything.
If people have columns, tables, keyspaces with name "check" that seems to
work already so they don't need to do anything:
CREATE TABLE ks.tb (id int check id > 0, val int check val > 0, primary
combination is a PR not being titled
appropriately and not closing it. It is very hard in that case to close it
because it will be exclusively manual work at that point which and the
probability that such a PR will be hanging there forever just got bigger.
On Mon, Apr 14, 2025 at 9:17 AM Štefan Miklošovič
ng opinion against it, I can start closing old
> PRs.
>
> Thanks!
> Bernardo
>
> On Apr 11, 2025, at 10:22 AM, Štefan Miklošovič
> wrote:
>
> I have a small script which scans GH pull requests (their titles) and
> looks into JIRA to see what is their status. When it is "
I have a small script which scans GH pull requests (their titles) and looks
into JIRA to see what is their status. When it is "resolved" it prints it
to the console. Then I go over the links of PRs and close them one by one.
This relies on the title of the PR to be in exact format (CASSANDRA-123 a
he
>> keyword?
>>
>> I also disagree that CHECK is a useful prefix to all constraints, and
>> would prefer consistency with Postgres here that also uses plain NOT NULL
>> for a NOT NULL constraint.
>>
>>
>> On 11 Apr 2025, at 17:05, Štefan Miklošovič
&g
disagree that CHECK is a useful prefix to all constraints, and
>> would prefer consistency with Postgres here that also uses plain NOT NULL
>> for a NOT NULL constraint.
>>
>>
>> On 11 Apr 2025, at 17:05, Štefan Miklošovič
>> wrote:
>>
>>
>> I
we aren’t matching the feature, why are we matching the
> keyword?
>
> I also disagree that CHECK is a useful prefix to all constraints, and
> would prefer consistency with Postgres here that also uses plain NOT NULL
> for a NOT NULL constraint.
>
>
> On 11 Apr 2025, at 17:
restrictions, I’d prefer eg REQUIRE JSON since this parses
> unambiguously to a human, whereas if we want to follow Postgres let’s do
> that but do it but that means eg CHECK is_json(field).
>
> On 11 Apr 2025, at 10:57, Štefan Miklošovič
> wrote:
>
>
> While modelling
, 2025 at 10:43 AM Benedict wrote:
> I would prefer require/expect/is over check
>
> On 11 Apr 2025, at 08:05, Štefan Miklošovič
> wrote:
>
>
> Yes, you will have it like that :) Thank you for this idea. Great example
> of cooperation over diverse domains.
>
> On Fri,
t; be quoted if used in table or column names, this will create
> incompatibility for existing user queries on upgrade.
>
> Otherwise, ignore me. :)
>
> Thanks,
>
> – Scott
>
> –––
> Mobile
>
> On Apr 10, 2025, at 7:47 AM, Jon Haddad wrote:
>
>
> This
+1, I am also getting questions about the versioning recently and people
themselves do not know what to call the next version like.
On Thu, Apr 10, 2025 at 8:28 PM Jon Haddad wrote:
> Bringing this back up.
>
> I don't think we have any reason to hold up renaming the version. We can
> have a se
Recently, David Capwell was commenting on constraints in one of Slack
threads (1) in dev channel and he suggested that the current form of "not
null" constraint we have right now in place, e.g like this
create table ks.tb (id int primary key, val int check not_null(val));
could be instead of that
Posting this to dev ML for better visibility as well.
On Thu, Mar 27, 2025 at 12:27 PM Steinmaurer, Thomas via user <
u...@cassandra.apache.org> wrote:
> Hello,
>
>
>
> any thoughts / reasons why ZSTD support for over-the-wire compression has
> been left out despite being a compression option for
sketches. This would be
> fine in my book, and probably much simpler.
>
> On 12 Mar 2025, at 11:37, Štefan Miklošovič
> wrote:
>
> Benedict,
>
> I have reached Datasketches community (1) and asked what they think about
> Clearspring and if it is convertible to Datasketc
to the new sketches. This would be
> fine in my book, and probably much simpler.
>
> On 12 Mar 2025, at 11:37, Štefan Miklošovič
> wrote:
>
> Benedict,
>
> I have reached Datasketches community (1) and asked what they think about
> Clearspring and if it is convertible to
up my priority list for the project, but I would
> support it if it scratches someone’s itch.
>
> On 3 Jan 2025, at 12:16, Štefan Miklošovič wrote:
>
>
> Okay ... first problems.
>
> These 2000 bytes I have mentioned in my response to Chris were indeed
> corre
That is cool but this still does not show / explain how it would look like
when it comes to dependencies needed for actually talking to storages like
s3.
Maybe I am missing something here and please explain when I am mistaken but
If I understand that correctly, for talking to s3 we would need to u
ve etc, it works fine for years and so
> on. They just want to upload SSTables upon snapshotting and call it a day.
>
> > I don't think we should force our worldview on them if they are not
> interested in it.
>
> It comes off *extremely* negative. You use the word "f
le you're having it with. Try to be more open
> minded.
>
>
> On Fri, Mar 7, 2025 at 2:28 AM Štefan Miklošovič
> wrote:
>
>> The only way I see that working is that, if everything was in a bucket,
>> if you take a snapshot, these SSTables would be "copied
k we should force our worldview on them if they are not
interested in it.
On Fri, Mar 7, 2025 at 11:02 AM Štefan Miklošovič
wrote:
> BTW, snapshots are quite special because these are not "files", they are
> just hard links. They "materialize" as regular files once u
t;upload".
On Fri, Mar 7, 2025 at 10:51 AM Štefan Miklošovič
wrote:
> Jon,
>
> all "big three" support mounting a bucket locally. That being said, I do
> not think that completely ditching this possibility for Cassandra working
> with a mount, e.g. for just uploading
tion? Well defined exceptions if we need to distinguish cases is one
>> that maybe springs to mind but perhaps there are others?
>>
>>
>> On 6 Mar 2025, at 08:39, Štefan Miklošovič
>> wrote:
>>
>>
>>
>> That is cool but this still does not sho
napshot-based
> querying of SSTables in an object store via Spark or similar platforms,
> with zero ETL or light cone contact with a production database process.
>
> The reason people care about object is that it’s 70%+ cheaper than flash -
> and 90%+ cheaper if the software querying
ike native backup,
> restoring from backup, recovering from local volumes can look VERY different
>
>
>
> On Mar 4, 2025, at 3:57 PM, Štefan Miklošovič
> wrote:
>
>
> For what it's worth, as it might come to somebody I am rejecting this
> altogether (which is not the
nted dirs for its simplicity and I guess that for copying files
it might be just enough. Plus we would not need to add all s3 jars on CP
either etc ...
On Tue, Mar 4, 2025 at 2:46 PM Štefan Miklošovič
wrote:
> I don't say that using remote object storage is useless.
>
> I am j
5 at 2:57 PM Brandon Williams wrote:
> A failing remote api that you are calling and a failing filesystem you
> are using have different implications.
>
> Kind Regards,
> Brandon
>
> On Tue, Mar 4, 2025 at 7:47 AM Štefan Miklošovič
> wrote:
> >
> > I don't
hroughput tradeoffs often make up for the latency.
>
> Outright dismissing object storage for Cassandra is short sighted - it
> needs to be done in a way that makes sense, not just blindly copying over
> the block access patterns to object.
>
>
> On Mar 4, 2025, at 11:19 AM, Štefa
I do not think we need this CEP, honestly. I don't want to diss this
unnecessarily but if you mount a remote storage locally (e.g. mounting s3
bucket as if it was any other directory on node's machine), then what is
this CEP good for?
Not talking about the necessity to put all dependencies to be a
The Project Management Committee (PMC) for Apache Cassandra has invited
Bernardo Botella to become a committer and we are pleased to announce that
he has accepted.
Please join us in welcoming Bernardo Botella to his new role and
responsibility in our project community.
Stefan Miklosovic
On behal
by it. I think a lot of operators will just want to be able to pop
> in some shell and be done with it. If I'm going to either write a whole
> bunch of java or take 3 minutes to call `rclone`, I'm definitely calling
> rclone.
>
> Overall, I like the idea of having a post-snapshot c
Congratulations Caleb, what a delivery (not only) in SAI department!
On Thu, Feb 20, 2025 at 11:07 PM Jon Haddad wrote:
> The PMC for Apache Cassandra is delighted to announce that Caleb Rackliffe
> has joined it's membership!
>
> Caleb has been a member of the community for 10 years and is one
The Project Management Committee (PMC) for Apache Cassandra
has invited Maxwell Guo and Dmitry Konstantinov to become committers and we
are pleased
to announce that they have accepted.
Please join us in welcoming Maxwell Guo and Dmitry Konstantinov to their
new role and
responsibility in our proje
n "users" violates check constraint
"users_age_check2"
DETAIL: Failing row contains (1, Joe, 20, active).
On Wed, Feb 19, 2025 at 1:07 PM Štefan Miklošovič
wrote:
> As said earlier, I am happy to support just simple "x > 10 AND x < 100"
> and be done with
gt; technically it is possible to cover quite sophisticated cases but I am not
> sure if it is worth the effort here ...
>
> Note: it was about 14 years ago when I had a deep dive into computational
> complexity theory last time, so please do not trust my words a lot :-)
>
>
> On
duplicities => duplicates :D Brandon spotted I was using this word some
time ago wrongly.
On Wed, Feb 19, 2025 at 6:37 AM Štefan Miklošovič
wrote:
> Great resources, thanks for that.
>
> It is not immediately obvious to me that this is 2-SAT but I do agree that
> this is a
isfiability (an example what quite a
> small change in constraints can change the picture dramatically: once we
> moved from 3SAT to 2SAT - it is polynomial).
>
> https://www.cs.ox.ac.uk/activities/constraints/publications/ComplexityLanguages.pdf
>
>
> Regards,
> Dmitry
>
Sorry, CEP-42
On Tue, Feb 18, 2025 at 8:54 PM Štefan Miklošovič
wrote:
> Hi list,
>
> We are doing good progress together with Bernardo when it comes to
> constraints which were merged recently (CEP-24).
>
> What I do now is that I try to "harden" it a little bit.
Hi list,
We are doing good progress together with Bernardo when it comes to
constraints which were merged recently (CEP-24).
What I do now is that I try to "harden" it a little bit. If you think about
that, a user could do something like this (currently)
ALTER TABLE ks.tb ALTER column1 CHECK col
Enough time has passed without anybody else stepping in so I think it is
reasonable to go with behaviour of STRICTLY_NOT_NULL renamed as NOT_NULL
and dropping the "weak" NOT_NULL as described in the original e-mail.
On Tue, Feb 11, 2025 at 9:44 AM guo Maxwell wrote:
> I think it may be better to
e avoid the confusion of
> allowing nulls.
> - It still adds value on its own.
>
> With, the “by default” not null doesn’t allow null or non present values
> on the insert statement, while we still support the more relaxed
> LOOSE_NOT_NULL for updates.
>
> Thoughts?
>
>
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
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
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
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
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.
>>>
>&g
The Cassandra team is pleased to announce the release of Apache Cassandra
version 4.0.17.
This release is a critical security release, fixing an issue found in [1]
and addressing CVE-2025-23015 [2].
Release 4.0.16 intended to fix CVE-2025-23015[2] but did not. This
release 4.0.17 does.
Apa
The Cassandra team is pleased to announce the release of Apache Cassandra
version 3.11.19.
This release contains a fix to performance regression found in [1].
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compr
The Cassandra team is pleased to announce the release of Apache Cassandra
version 3.0.32.
This release contains a fix to performance regression found in [1].
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compro
The vote has passed with 4 binding +1s and no vetoes.
On Thu, Feb 6, 2025 at 1:02 PM Brandon Williams wrote:
> +1
>
> Kind Regards,
> Brandon
>
> On Thu, Feb 6, 2025 at 1:04 AM Štefan Miklošovič
> wrote:
> >
> > Proposing the test build of Cassandra
The vote has passed with 4 binding +1s and no vetoes.
On Thu, Feb 6, 2025 at 1:02 PM Brandon Williams wrote:
> +1
>
> Kind Regards,
> Brandon
>
> On Thu, Feb 6, 2025 at 1:00 AM Štefan Miklošovič
> wrote:
> >
> > Proposing the test build of Cassandra
1 - 100 of 362 matches
Mail list logo
