I'm strongly support removal of MVCC from master. At the current state it bloats code base and should be reworked from scratch using separate code base.
чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <ilya.kasnach...@gmail.com>: > Hello! > > Please keep in mind that you need to create a separate proposal voting > thread if you really like it to count. I wonder if Dmitry Pavlov can help > us with the procedure. > > Otherwise, I think it makes total sense to restrict MVCC clusters to only > have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in > our current implementation) and no ATOMIC caches at all. > > Regards, > -- > Ilya Kasnacheev > > > чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <mmu...@apache.org>: > > > Ilya, > > > > > > 1. MVCC support requires code maintenance for other developed features > > even if has not used and disabled. Currently, we've got an x2 level of > > difficulty for implementation of new features. > > > > 2. It would be much easy to develop and support clusters with > > mvcc-caches only rather than have a mixed configuration. With this > > option we can dramatically reduce the amount of codebase removing from > > mvcc-branch local, atomic, tx caches. > > > > > > So, I'm +1 to remove it from the master branch and mark the current > > API with @IgniteExperimental. > > > > On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <ilya.kasnach...@gmail.com> > > wrote: > > > > > > Hello! > > > > > > Why would we drop MVCC!? > > > > > > I can totally imagine a scenario where a large Ignite user surfaces > with > > > fixes for MVCC mode, if it is kept as an experimental feature. Then > maybe > > > it will graduate to beta some time in future. > > > > > > If it does too much strain on the TC, let's discuss that, but I don't > > > remember problems with TC load lately, so maybe this is a moot point. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <nizhi...@apache.org>: > > > > > > > > By the way, is there any reason to have this code in the master > > branch > > > > > > > > I support removal MVCC from master. > > > > > > > > > > > > > 6 февр. 2020 г., в 15:26, Andrey Gura <ag...@apache.org> > написал(а): > > > > > > > > > > +1 > > > > > > > > > > By the way, is there any reason to have this code in the master > > > > > branch? It seems feature is in unsupportable state and just wastes > TC > > > > > time and our effort to support MVCC related tests. > > > > > > > > > > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk > > > > > <alexey.goncha...@gmail.com> wrote: > > > > >> > > > > >> Agree, let's mark MVCC experimental. > > > > >> > > > > >> Stephen, the annotation serves as an additional > documentation-style > > > > marker. > > > > >> For now there are no compile-time warnings when the API is used. > > > > >> > > > > >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington < > > > > >> stephen.darling...@gridgain.com>: > > > > >> > > > > >>> Yes! I’ve already seen people try to use this without awareness > > that > > > > it’s > > > > >>> not production ready. > > > > >>> > > > > >>> What happens with the annotation, incidentally? Is it just in the > > > > >>> documentation or do you get a compile-time warning? > > > > >>> > > > > >>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <nizhi...@apache.org> > > wrote: > > > > >>>> > > > > >>>> Hello, Igniters. > > > > >>>> > > > > >>>> Should we mark MVCC feature with the new @IgniteExperimental? > > > > >>>> > > > > >>>> We explicitly note users that MVCC has beta status, for now [1] > > > > >>>> > > > > >>>>> Beta version of Transactional SQL and MVCC > > > > >>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta > > > > >>> versions to allow users to experiment and share feedback. > > > > >>>>> This version of Transactional SQL and MVCC should not be > > considered > > > > for > > > > >>> production. > > > > >>>> > > > > >>>> > > > > >>>> [1] > > > > https://apacheignite.readme.io/docs/multiversion-concurrency-control > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > > > -- Best regards, Alexei Scherbakov
