Hello everyone : What is the final conclusion of this discuss ? As https://issues.apache.org/jira/browse/CASSANDRA-18934 has been created , and we know that for system table of different c* version , the schema info may be different as we may add or delete column or modify the table properties in different versions. For 18934 , because I have introduced a new column " compaction_properties" for compaction_history table in 5.0. So the downgrade test to 4.1 failed at the 4.1 node startup stage due to 4.1’s code encountering an incompatible persisted column "compaction_properties".
So now for me, I might want to know, which solution did everyone finally decide to use for the sstable ? 1. Are our current downgrades intended to only support specific version downgrades, like 5.0 -> 4.1 ? 2.Can we modify the low version code now ? that is say , if we add some feature for example in 4.1.0 and that means we may only support downgrade to 4.1.1 3.If we choose to rewrite sstable, please help consider the differences in system tables between different versions. Jacek Lewandowski <lewandowski.ja...@gmail.com> 于2023年3月6日周一 16:58写道： > A bit of organization - I've created > https://issues.apache.org/jira/browse/CASSANDRA-18300 epic to track > tickets related to the downgradability. Please add the tickets you are > aware of. > > thanks > - - -- --- ----- -------- ------------- > Jacek Lewandowski > > > czw., 23 lut 2023 o 17:47 Benedict <bened...@apache.org> napisał(a): > >> Either way, it feels like this has become much more of a big deal than it >> needed to. >> >> I would prefer the pending patches to avoid breaking compatibility, as I >> think they can do it easily. But, if we agree to block release until we can >> double back to fix it with versioned writing (which I agree with Jacek are >> LHF - I think we literally just need a method that chooses the descriptor >> version) then let’s not further agonise over this. >> >> Alternatively I’d be happy to work with the authors to get this done >> alongside their work, as I don’t think it would hold anything up. We just >> need something to pick a descriptor besides latest on write, everything >> else is basically there for these patches. >> >> >> On 23 Feb 2023, at 16:37, Henrik Ingo <henrik.i...@datastax.com> wrote: >> >> >> Right. So I'm speculating everyone else who worked on a patch that breaks >> compatibility has been working under the mindset "I'll just put this behind >> the same switch". Or something more vague / even less correct, such as >> assuming that tries would become the default immediately. >> >> At least in my mind when we talk about the "switch to enable tries" I do >> also consider things like "don't break streaming". So I guess whether one >> considers "a switch" to exist already or not, might be subjective in this >> case, because people have different assumptions on the definition of done >> of such a switch. >> >> henrik >> >> On Thu, Feb 23, 2023 at 2:53 PM Benedict <bened...@apache.org> wrote: >> >>> I don’t think there’s anything about a new format that requires a >>> version bump, but I could be missing something. >>> >>> We have to have a switch to enable tries already don’t we? I’m pretty >>> sure we haven’t talked about switching the default format? >>> >>> On 23 Feb 2023, at 12:12, Henrik Ingo <henrik.i...@datastax.com> wrote: >>> >>> >>> On Thu, Feb 23, 2023 at 11:57 AM Benedict <bened...@apache.org> wrote: >>> >>>> Can somebody explain to me why this is being fought tooth and nail, >>>> when the work involved is absolutely minimal? >>>> >>>> >>> I don't know how each individual has been thinking about this, but it >>> seems to me just looking at all the tasks that at least the introduction of >>> tries is a major format change anyway - since it's the whole point - and >>> therefore people working on other tasks may have assumed the format is >>> changing anyway and therefore something like a switch (is this what is >>> referred to as the C-8110 solution?) will take care of it for everyone. >>> >>> I'm not sure there's consensus that such a switch is a sufficient >>> resolution to this discussion, but if there were such a consensus, the next >>> question would be whether the patches that are otherwise ready now can >>> merge, or whether they will all be blocked waiting for the compatibility >>> solution first. And possibly better testing, etc. Letting them merge would >>> be justified by the desire to have more frequent and smaller increments of >>> work merged into trunk... well, I'm not going to repeat everything from >>> that discussion but the same pro's and con's apply. >>> >>> henrik >>> -- >>> >>> Henrik Ingo >>> >>> c. +358 40 569 7354 >>> >>> w. www.datastax.com >>> >>> >>> <https://urldefense.com/v3/__https://www.facebook.com/datastax__;!!PbtH5S7Ebw!dOQqeDGZHgRdaV7zT4J-u7QGa4b2HCSNBgF8KrDldGjvy_guOGUws3L2sV2X5y_vzNYF7iZ85aa0n0n_sPsT$> >>> <https://twitter.com/datastax> >>> <https://urldefense.com/v3/__https://www.linkedin.com/company/datastax/__;!!PbtH5S7Ebw!dOQqeDGZHgRdaV7zT4J-u7QGa4b2HCSNBgF8KrDldGjvy_guOGUws3L2sV2X5y_vzNYF7iZ85aa0n2bcAuFd$> >>> <https://github.com/datastax/> >>> >>> >> >> -- >> >> Henrik Ingo >> >> c. +358 40 569 7354 >> >> w. www.datastax.com >> >> <https://www.facebook.com/datastax> <https://twitter.com/datastax> >> <https://www.linkedin.com/company/datastax/> >> <https://github.com/datastax/> >> >>
