[DISCUSS] cep-15-accord, cep-21-tcm, and trunk

We've already talked a bit about how and when the current Accord feature branch should merge to trunk. Earlier today, the cep-21-tcm branch was created

Re: hsqldb test dependency in simulator code

Quickly looking I think we can switch to org.agrona.collections.Long2LongHashMap, the key isn’t the “correct” type (long when we want int) but isn’t too hard to switch. Few differences in the semantics need to be handled, but not much 1) get of non-defeiled key should throw

Re: [DISCUSS] CEP-21 Ongoing Development

Hi, further to my previous mail I've just pushed a new branch, cep-21-tcm, to the ASF repo. This represents the majority of the work to date on CEP-21 and is based on recent trunk (7ad746cc83). As you can see from Circle[1], there are a number of test failures at the moment, many of which are

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

It's always seemed a little odd to me that we drop all the "read old format" code given how little maintenance that code takes over time. The ability to have a C* node read older format SSTables into perpetuity *seems* like a pretty compelling usability feature to me (for some of the reasons

Re: Should we cut some new releases?

+1 On Tue, Mar 14, 2023, at 7:50 AM, Aleksey Yeshchenko wrote: > +1 > >> On 14 Mar 2023, at 05:50, Berenguer Blasi wrote: >> >> +1 >> >> On 13/3/23 21:25, Jacek Lewandowski wrote: >>> +1 >>> >>> pon., 13 mar 2023, 20:36 użytkownik Miklosovic, Stefan >>> napisał: Yes, I was waiting for

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

On Mon, Mar 13, 2023 at 5:54 PM Mick Semb Wever wrote: > Personally I am not in favour of keeping, or recommending users use, > code we don't test. How much effort would it be to have some simple smoke tests? I think we should make sure nothing gets indirectly broken if we're going to keep it

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

I’m not sure we have an explicit rule at the moment. Would probably based on calendar time in addition to release versions if we had one. Addressing these on case by case basis for now is fine IMO. I’d say the general principle should be treat extended compatibility (between releases in

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

Hi, Do we consider it as an occasional exception to the rule or we will define a rule which explicitly says how many versions the user can expect to be supported? I'm slightly towards keeping the support for Mx versions just because the time gap between 3.11 and 4.0 was very long. I suppose many

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

Agreed. I also think it is worthwhile to keep that code around. Given how widespread C* 3.x use is, I do not think it is worthwhile dropping support for those sstable formats at this time. -Jeremiah > On Mar 14, 2023, at 9:36 AM, C. Scott Andreas wrote: > >  > I agree with Aleksey's view

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

I agree with Aleksey's view here.To expand on the final point he makes re: requiring SSTables be fully rewritten prior to rev'ing from 4.x to 5.x (if the cluster previously ran 3.x) –This would also invalidate incremental backups. Operators would either be required to perform a full snapshot

Re: hsqldb test dependency in simulator code

Do we have the hsqldb library just for a primitive oriented equivalent of Map? If this is test code only that seems like a pretty easy thing to replace and I would vote to implement that so we can fully drop the dependency. Cheers, Derek On Tue, Mar 14, 2023 at 5:49 AM Miklosovic, Stefan <

Re: hsqldb test dependency in simulator code

I’m sure we can use a different hash map there. > On 14 Mar 2023, at 11:49, Miklosovic, Stefan > wrote: > > Hi list, > > while removing Hadoop code in trunk, as agreed on ML recently, I did that but > we need to do this (1). By removing all Hadoop dependencies, we also removed > hsqldb

Re: [DISCUSS] Remove deprecated CQL functions dateof and unixtimestampof on 5.0

I have created https://issues.apache.org/jira/browse/CASSANDRA-18328 for removing the deprecated functions, as part of CASSANDRA-18306 epic. On Mon, 13 Mar 2023 at 12:28, Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote: > Actually,

Re: Should we cut some new releases?

+1 > On 14 Mar 2023, at 05:50, Berenguer Blasi wrote: > > +1 > > On 13/3/23 21:25, Jacek Lewandowski wrote: >> +1 >> >> pon., 13 mar 2023, 20:36 użytkownik Miklosovic, Stefan >> mailto:stefan.mikloso...@netapp.com>> napisał: >>> Yes, I was waiting for CASSANDRA-18125 to be in. >>> >>> I can

hsqldb test dependency in simulator code

Hi list, while removing Hadoop code in trunk, as agreed on ML recently, I did that but we need to do this (1). By removing all Hadoop dependencies, we also removed hsqldb library we surprisingly rely on so I am putting it back. Honestly, I do not know if people are even aware of the fact we

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

Raising messaging service minimum, I have a less strong opinion on, but on dropping m* sstable code I’m strongly -1. 1. This is code on a rarely touched path 2. It’s very stable and battle tested at this point 3. Removing it doesn’t reduce much complexity at all, just a few branches are