> +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> 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> 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> 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> 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> > >>> Sent: Wednesday, December 11, 2024 13:09 > >>> To: dev@cassandra.apache.org > >>> Cc: Miklosovic, Stefan; 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> 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 > >>> > >> > > > >
