Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT

+1 Le jeu. 13 avr. 2023 à 08:56, Tommy Stendahl via dev < dev@cassandra.apache.org> a écrit : > +1 (nb) > > -Original Message- > *From*: Brandon Williams > > *Reply-To*: dev@cassandra.apache.org > *To*: dev@cassandra.apache.org > *Subject*: Re: [VOTE] Release Apache Cassandra 4.0.9 - SEC

Re: [DISCUSS] CEP-29 CQL NOT Operator

Somebody correct me if I am wrong but "partition key" itself is not enough (primary keys = partition keys + clustering columns). It will require ALLOW FILTERING when clustering columns are not specified either. create table ks.tb (p1 int, c1 int, col1 int, col2 int, primary key (p1, c1)); select

Re: [DISCUSS] CEP-29 CQL NOT Operator

Aha I get what you all mean: select * from ks.tb where p1 = 1 and c1 = 2 and col2 = 1; this will required ALLOW FILTERING too. I agree that this is a little bit too much, we provided all keys but it still complains. We could probably lower the restrictions here. __

Re: [DISCUSS] CEP-29 CQL NOT Operator

On Thu, Apr 13, 2023 at 10:20 AM Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > Somebody correct me if I am wrong but "partition key" itself is not enough > (primary keys = partition keys + clustering columns). It will require ALLOW > FILTERING when clustering columns are not specifie

Re: [DISCUSS] CEP-29 CQL NOT Operator

Indeed requiring AF for "select * from ks.tb where p1 = 1 and c1 = 2 and col2 = 1", where p1 and c1 are all the columns in the primary key, sounds like a bug. I think the criterion in the code is that we require AF if there is any column restriction that cannot be processed by the primary key or a

Re: [DISCUSS] CEP-29 CQL NOT Operator

The documentation is wrong. ALLOW FILTERING has always meant that “rows will need to be materialized in memory and accepted or rejected by a column filter” aka the full primary key was not specified and some other column was specified.  It has never been about multiple partitions.Basically “will th

New episode of The Apache Cassandra (R) Corner podcast!

Link to the next episode: https://drive.google.com/file/d/1E9HTuwkRf9W6W-9tM6PB0da8SRAd3g5j/view?usp=sharing s2e5 - Rahul Singh (Anant) (You may have to download it to play) It will remain in staging for 72 hours, going live (assuming no objections) by Sunday, April 16th. If anyone should have a

New episode of The Apache Cassandra (R) Corner podcast!

Link to the next episode: https://drive.google.com/file/d/1E9HTuwkRf9W6W-9tM6PB0da8SRAd3g5j/view?usp=sharing s2e5 - Rahul Singh (Anant) (You may have to download it to play) It will remain in staging for 72 hours, going live (assuming no objections) by Sunday, April 16th. If anyone should have a

Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT

+1 On Thu, Apr 13, 2023, at 3:17 AM, Benjamin Lerer wrote: > +1 > > Le jeu. 13 avr. 2023 à 08:56, Tommy Stendahl via dev > a écrit : >> +1 (nb) >> >> -Original Message- >> *From*: Brandon Williams > > >> *Reply-To*: dev@cassandra.apac

(CVE only) support for 3,11 beyond published EOL

All, There have been several discussions on slack [1], [2] to support 3.11 beyond the date stated on the web [3] which is May-July 23 and given it's April that's an unlikely date. Given that there are still a sizable number of users on 3.11 in [2] we talked about a CVE only support for some ti

Re: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT

+1 (Recently learned anyone can vote so using my new discovered powers) From: Josh McKenzie Sent: Thursday, April 13, 2023 6:59 AM To: dev Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT +1 On Thu, Apr 13, 2023, at 3:17 AM, Benjam

Re: (CVE only) support for 3,11 beyond published EOL

> > There have been several discussions on slack [1], [2] to support 3.11 beyond > the date stated on the web [3] which is May-July 23 and given it's April > that's an unlikely date. > Strictly speaking it is maintained until the 5.0 GA release. We should update the downloads page accordingly.

Re: (CVE only) support for 3,11 beyond published EOL

> We already have an understanding and precedence in place that CVEs on > the previous unmaintained branch are addressed and released. Correct me if I'm wrong German, but the question I got from your email was effectively "If we consider formalizing our commitment to fixing CVE's on older branch

Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

Josh, We already have an understanding and precedence in place that CVEs on the previous unmaintained branch are addressed and released. Correct me if I'm wrong German, but the question I got from your email was effectively "If we consider formalizing our comm

Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

> > Yes, this would be great. Right now users are confused what EOL means and > what they can expect. > > I think the project would need to land on an agreed position. I tried to find any reference to my earlier statement around CVEs on the latest unmaintained branch but could not find it (I'm su

Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

To me, as this is an open source project, we, the community, do not have to do anything, we can, but we are not obliged to, and we usually do that because we want to :-) To me, EOL means that we move focus to newer releases. Not that we are forbidden to do anything in the older ones. One formal po