Why would ant get in the way? We already build multiple jars, and accord will be a submodule. We have far more organisational issues to overcome than ant.
I have for a while advocated for a shared lib to also share between Harry, accord, dtests etc
I am however not 100% sure about splitting read/write path, at least not as first posited. The idea of maintaining it as an API for dropping in different jars is a whole other world of potential pain I don’t want to countenance. Supporting eg bulk readers or writers or other integrations seems pretty feasible though. On 12 Dec 2024, at 16:53, Paulo Motta <pa...@apache.org> wrote:
>
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?
This is a contentious/controversial topic, but the more I work with gradle the more I lean towards ant's simplicity. That said, I'd support moving away if it becomes a technical blocker to break up cassandra-all - and if this happen I would vote for maven as replacement. :-D
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
>>>
>>
>
|
