On 2024/06/21 12:00:43 Mick Semb Wever wrote:
> Agreeing with Stefan, Brandon, and Yifan here…
>
Yeah, I agree as well. We want to either have an alternative to MAXWRITETIME
or preserve the existing functionality.
> We are ready to cut 5.0-rc1 and this thread (and any resulting work) is the
> on
>
> Doesn’t an UPDATE statement creates a row if the partition key does not
> exist?
Things are more tricky that what the documentation is letting people
believe.
Internally, UPDATE does not really create a row. It creates a set of
updates for a row. At the CQL level it looks like a row exists b
Hi everyone,
I would like to start the voting for CEP-40 as all the feedback in the
discussion thread seems to be addressed.
Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-40%3A+Data+Transfer+Using+Cassandra+Sidecar+for+Live+Migrating+Instances
Discussion thread:
https://list
Seems to me that this should use the same behavior as a counter unless IF
EXISTS is supplied.
I can see a solid argument for failing though, if the argument is that only
counters behave that way, vs increment / decrement.
On Fri, Jun 21, 2024 at 4:32 PM Josh McKenzie wrote:
> What about abort
Hi all,
I did not hear anything in the last 10+ days. I am taking it as a positive
sign and proceeding to the voting stage for this CEP.
Thanks!
Hari
On Fri, Jun 7, 2024 at 10:26 PM Venkata Hari Krishna Nukala <
n.v.harikrishna.apa...@gmail.com> wrote:
>
> Summarizing the discussion happened so
The test build of Cassandra 5.0-rc1 is available.
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/
What about aborting the transaction / raising an exception if you try and do an
incremental operator against a non-existent PK?
The reasonable inferred intent of the user is to change a value that's expected
to be there, so if it's not there it's an error case right? Otherwise you'd
append "IF
Thank you Josh and congratulations Dinesh!
On Thu, 20 Jun 2024 at 11:52 Josh McKenzie wrote:
> Another PMC Chair baton pass incoming! On behalf of the Apache Cassandra
> Project Management Committee (PMC) I would like to welcome and congratulate
> our next PMC Chair Dinesh Joshi (djoshi).
>
> Di
Agreeing with Stefan, Brandon, and Yifan here…
We are ready to cut 5.0-rc1 and this thread (and any resulting work) is the
only current blocker.
The argument for leaving things as they are, is…
- MAXWRITETIME as-is is valuable. and is done.
- We can't mark it deprecated until 18085 lands (ref
Third time's a charm.
In order to support that, we would need to include the second commit (1) of
this PR.
I am stuck on (2). Something happened in 5.0 in the meanwhile that this is
not working anymore.
If anybody feels brave enough to fix that, be my guest, I am under the time
pressure with oth
I should rather say that tests act as if the application of collection
functions to non-collection types would work but that functionality is not
in the prod code yet.
On Fri, Jun 21, 2024 at 1:17 PM Štefan Miklošovič
wrote:
> I do not feel comfortable to rush this.
>
> For completeness, this is
I do not feel comfortable to rush this.
For completeness, this is the PR I managed to rebase
https://github.com/apache/cassandra/pull/3383
This is CI, bunch of tests are failing
https://app.circleci.com/pipelines/github/instaclustr/cassandra/4406/workflows/d46e98e5-e931-41fc-ae51-a7202f3945e3
Nothing else is blocking the release currently, so unless 18085 is
ready to commit right now, I don't think it's worth delaying the
release any further.
Kind Regards,
Brandon
On Fri, Jun 21, 2024 at 5:32 AM Jon Haddad wrote:
>
> I’m on vacation, so I’ll keep this brief. While its not the end of
I’m on vacation, so I’ll keep this brief. While its not the end of the
world, I think shipping a feature that’s immediately deprecated reflects
poorly on the project and our ability to manage it.
I don’t know how much work need to be done to merge that patch, so its hard
to say if we should wait
>
> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
> first add CASSANDRA-18085.
>
This statement is inaccurate.
Before 5.0-alpha1 there was no equivalent function for either MAXWRITETIME
or 18085.
As Mick and Yifan say, we would need to merge CASSANDRA-18085 to fill the
gap. I looked into that and it does not apply cleanly / has some merge
conflicts.
In CASSANDRA-18085, Andres started a thread (1) which gets complicated
pretty fast and honestly I have not read it all yet to give any meaning
On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe wrote:
> 100% Option 1. Once it's out in GA release we're stuck with it so any
> short term disruption to adopters of pre-release versions is a trivial
> price to pay.
Sam, Jeremiah, Jeff, Jon,
we need some clarity on this.
To remove MAXWRITETIM
100% Option 1. Once it's out in GA release we're stuck with it so any short
term disruption to adopters of pre-release versions is a trivial price to pay.
> On 20 Jun 2024, at 17:46, Štefan Miklošovič wrote:
>
> List,
>
> we need your opinions about CASSANDRA-18078.
>
> That ticket is about
18 matches
Mail list logo
