Yes, those explanations sound very reasonable to me as well and I'll push the implementation soon.
Thank you guys On 2021/10/26 18:21:44, Joshua McKenzie <jmcken...@apache.org> wrote: > +1 to Benedict's perspective here. Supporting both sstable ID paradigms > should be relatively trivial and low cost to maintain going forward. > > On Tue, Oct 26, 2021 at 7:54 AM bened...@apache.org <bened...@apache.org> > wrote: > > > I think it is probably acceptable to prevent downgrades once a new feature > > is enabled, as the exposure risk is limited to that one feature. The user > > can test the new version to ensure everything else works satisfactorily > > before committing to this one feature. > > > > A downgrade tool would also be possible to produce, but probably the > > additional utility is limited. > > > > I think this particular feature is probably easy enough to maintain as > > permanently optional, simply maintaining two system tables: one for the old > > generation format, one for the new. So long as the user doesn’t use the new > > format, it remains forever downgradeable. Though perhaps one day we may > > want to force users to migrate, I don’t think there’s any rush, and the > > important thing to avoid is providing users no version buffer to escape new > > bugs – if a major version later we force upgrade, then they have a whole > > range of major versions to downgrade to that still support this feature > > (but perhaps avoid some other new issue) > > > > > > > > From: Jacek Lewandowski <lewandowski.ja...@gmail.com> > > Date: Tuesday, 26 October 2021 at 12:01 > > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > > Subject: Re: [DISCUSS] How to implement backward compatibility > > (CASSANDRA-17048) > > Though, the user is unable to test the new feature without enabling it. And > > when it is enabled, the user is unable to revert it. > > > > - - -- --- ----- -------- ------------- > > Jacek Lewandowski > > > > > > On Tue, Oct 26, 2021 at 12:54 PM Bowen Song <bo...@bso.ng.invalid> wrote: > > > > > Personally, I would prefer a transition period in which the new feature > > > is not enabled by default. This not only makes version upgrading easier, > > > it also allows the user to stay on the old behaviour if they experience > > > any issue with the new feature (e.g.: bugs in the new feature, or edge > > > use cases / 3rd party tools depending on the old behaviour) until the > > > issue is resolved. > > > > > > On 26/10/2021 10:21, Jacek Lewandowski wrote: > > > > Hi, > > > > > > > > In short, we are discussing UUID based sstable generation identifiers > > in > > > https://issues.apache.org/jira/browse/CASSANDRA-17048. > > > > > > > > The question which somehow hold us is support for downgrading. Long > > > story short, when we generate new sstables with uuid based ids, they are > > > not readable by older C* versions. > > > > > > > > 1. should we implement a downgrade tool? (it may be quite complex) > > > > 2. should we let users enable the new uuid ids later when they are sure > > > they will not downgrade in the future? > > > > > > > > Thanks, > > > > Jacek > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
