These are all good ideas but in practical terms I think that will not happen until we are out of Ant as doing this multi jar / subproject mumbo jumbo is not too much appealing to ... anybody?
________________________________________ From: Paulo Motta <pa...@apache.org> Sent: Thursday, December 12, 2024 17:35 To: dev@cassandra.apache.org Subject: Re: Supporting 2.2 -> 5.0 upgrades EXTERNAL EMAIL - USE CAUTION when clicking links or attachments > +1 on moving the read/write logic into its own jar. +1, not only read-write logic but anything used by both the server and subprojects (ie. cassandra-sidecar), for example JMX Mbeans and other interfaces. I think one way to do that would be to split cassandra-all into cassandra-server and cassandra-common (anything used by both subprojects and server), but not sure if this would be feasible or what it would take. If there's loose agreement this would be a feasible path I'd be happy to create a JIRA to investigate what this would take. On Thu, Dec 12, 2024 at 11:26 AM Doug Rohrer <droh...@apple.com<mailto:droh...@apple.com>> wrote: +1 on moving the read/write logic into its own jar. Doug > On Dec 11, 2024, at 7:21 PM, David Capwell > <dcapw...@apple.com<mailto:dcapw...@apple.com>> wrote: > > From a disk format point of view the only thing I remember was the disk type > bug with UDTs. Bringing that logic back was hard as the type system (in 5.0) > tries to avoid allowing construction of invalid states, and we would need to > weaken that in order to enable the migration. Assuming the user migrated from > 3.x to 4.x then the sstable metadata should have been rewritten to fix this > bug. > > One thought (though know its a ton of effort).. we have talked about for a > long time about moving the reading/writing logic into its jar (so tools don’t > need cassandra-all and can limit the dependencies)… if we did that we could > try to solve this as an out of process migration… have the 2.2 reader then > write using 6.0 writer (ignoring compact storage… )… > >> On Dec 11, 2024, at 4:59 AM, Benedict >> <bened...@apache.org<mailto:bened...@apache.org>> wrote: >> >> I think 3.11 supported upgrade from 2.2, but I haven’t checked. I am fairly >> sure 4.x supported upgrade from 3.0.x also. >> >> >>> On 11 Dec 2024, at 12:53, Miklosovic, Stefan via dev >>> <dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>> wrote: >>> >>> I see. That makes sense. I think that by 3.x you meant basically the >>> latest 3.11, right? I guess 2.2 -> 3.0 already works, we would just try to >>> support 2.2 -> 3.11 straight away. I need to check where we are at in that >>> area. >>> >>> ________________________________________ >>> From: Benedict <bened...@apache.org<mailto:bened...@apache.org>> >>> Sent: Wednesday, December 11, 2024 13:09 >>> To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org> >>> Cc: Miklosovic, Stefan; >>> dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>; Miklosovic, >>> Stefan >>> Subject: Re: Supporting 2.2 -> 5.0 upgrades >>> >>> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments >>> >>> >>> >>> >>> 2.2 is particularly hard because of the major storage format changes that >>> took place. >>> >>> I think if we want to retain (restore) upgrade support from 3.x I would >>> support that, but 2.x is probably too burdensome and likely to have too >>> many hard edges. >>> >>> I think if users only had to upgrade 2.2->3.x then eg 3.x->6.0 that would >>> be a pretty friendly upgrade path all things considered. >>> >>>> On 11 Dec 2024, at 12:03, Miklosovic, Stefan via dev >>>> <dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>> wrote: >>>> >>>> Hey, >>>> >>>> I want to fork the thread where we are mentioning that 2.2 -> 5.0 would be >>>> cool to support. >>>> >>>> I was involved in checking that offline upgrades from 3.0 to 5.0 work and >>>> fixed few issues along the way (1), hence I can imagine that supporting >>>> 2.2 -> 5.0 would be basically the same thing just on steroids and more >>>> involved? Anyway, having a stab into this is not useless at all, I will at >>>> least go deep into the upgrade stuff I have never given a lot of thought >>>> to which is good learning experience. >>>> >>>> Any tips where to start? Was any progress done by anybody already in this >>>> matter to not start from zero? >>>> >>>> (1) >>>> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/CASSANDRA-19002__;!!Nhn8V6BzJA!RFZoz6sQSrP_qLd0K_eNWO3UAc1s8mTT5SkFalUMwM7_l9gWfb4cnfTFvdY68zsh5-REW7T8ALTPQwqMM_gWWSyp$ >>>> >>>> Regards >>> >> >
