Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Sure. > On 6 Dec 2022, at 18:14, Mick Semb Wever wrote: > >> Let’s get these fixes in and roll a pure RC2. > > > > Given that we're talking about two one-liners, just changing time units, what > are folks thoughts about skipping rc2 and just re-cutting 4.1.0 (GA) ? > > (I agree with the

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

If the functionality truly has never actually worked, then throwing an error that MAX is not supported for collections seems reasonable. But we should throw an error, I do not think we should have functions that aggregate across rows and functions that operate within a row use the same name.

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Here is CASSANDRA-18097 with the bug fix for the performance regression encountered with 100 partitions in V2. On Mon, Dec 5, 2022 at 2:05 PM Marianne Lyne Manaog < marianne.man...@ieee.org> wrote: > Following on what Matt said: > > - Here

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

> I am simply trying to understand the need to put in place a process that has > a high cost in terms of time and effort for small changes. It is an additional cost, but it’s not a high cost. And certainly not a high *marginal* cost - when compared to all the admin involved in getting a patch

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

> > Let’s get these fixes in and roll a pure RC2. > Given that we're talking about two one-liners, just changing time units, what are folks thoughts about skipping rc2 and just re-cutting 4.1.0 (GA) ? (I agree with the rules, and am in favour of making the exception.)

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

As far as I am aware it has never worked in a release, and so deprecating it is probably not as challenging as you think. Only folk that have been able to parse the raw bytes of the collection in storage format would be affected - which we can probably treat as zero. > On 6 Dec 2022, at

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

> 1. I think it is a mistake to offer a function MAX that operates over rows > containing collections, returning the collection with the most elements. This > is just a nonsensical operation to support IMO. We should decide as a > community whether we “fix” this aggregation, or remove it. The

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

> > It’s not the first time you bring up trust, I feel, but there really is no > need to go all defensive here. I am not defensive. I am simply trying to understand the need to put in place a process that has a high cost in terms of time and effort for small changes. So far nobody has been able

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Aleksey, I absolutely agree with the point users will be able to give more input, help early on with feedback etc. But I struggle to see why having two sentences explicitly to mention on the ticket the exact API change, which can be even in a new separate required field is not enough to trigger

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

If the big works are already accompanied by discussions, I do not see a reason a list pointing to Jira tickets with small API changes could not serve our needs. A nice label and commitment that API change will be brought in the description with a few sentences seems more than enough to me. Also,

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Public APIs are 1) essentially forever-lasting and 2) are what our users actually get to interact with. A suboptimal public API can be annoying to work with at best, and at worst force and cement suboptimal implementations. The goal here is to make sure that whatever public API changes we

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

I am sorry but I still do not understand what problem we are trying to solve. All examples given so far have been about significant features which we already discuss on this mailing not about minor changes that happen multiple times per week. Is it a trust issue ?

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

Thanks Andres, I think community input on direction here will be invaluable. There’s a bunch of interrelated tickets, and my opinions are as follows: 1. I think it is a mistake to offer a function MAX that operates over rows containing collections, returning the collection with the most

Aggregate functions on collections, collection functions and MAXWRITETIME

This will require some long introduction for context: The MAX/MIN functions aggregate rows to get the row with min/max column value according to their comparator. For collections, the comparison is on the lexicographical order of the collection elements. That's the very same comparator that is

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Switching to -1 then. Let’s get these fixes in and roll a pure RC2. > On 6 Dec 2022, at 10:53, Benedict wrote: > > There’s another 1-line fix needed with the patch, and some tests, that I (or > someone else) can likely post later today. It might be worth also giving Matt > and Marianne a day

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

There’s another 1-line fix needed with the patch, and some tests, that I (or someone else) can likely post later today. It might be worth also giving Matt and Marianne a day or two to run some further tests to confirm everything is working as expected. > On 6 Dec 2022, at 09:15, Mick Semb

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Marianne and Matt, are you saying that this v1->v2 performance degradation is more than just CASSANDRA-18086 ? If so, what's the eta for a ticket created for it? On Tue, 6 Dec 2022 at 00:07, Marianne Lyne Manaog wrote: > Following on what Matt said: > > - Here is the link to the Cassandra repo