Hi, all! In private discussion with Ivan Daschinsky and Anton Vinogradov we discussed optional scenarios when such a situation is possible.
Then I agree with Stan's proposal: 1. Revert deprecation. 2. Change default value in 2.15. 3. Notify users in release notes, an exception message - how to change the behavior back. If there are no objections, I'll revert a commit on Monday. Thanks! On Tue, Oct 25, 2022 at 3:43 PM Maksim Timonin <timoninma...@apache.org> wrote: > Hi, Stan! > > >> Say, I have an ATOMIC and TRANSACTIONAL caches in my system, and I need > to change them at the same time > > Looks very unreliable. Which guarantees users expect from Ignite in this > case? For example - transaction rollbacks but atomic change (within this > tx) succeeds, and vice versa. I'm not sure Ignite should allow this > behaviour. Do you know real real cases when Ignite is used in such a way? > > > On Tue, Oct 25, 2022 at 3:27 PM Anton Vinogradov <a...@apache.org> wrote: > >> >> WDYT? >> +1 >> >> On Tue, Oct 25, 2022 at 11:40 AM Stanislav Lukyanov < >> stanlukya...@gmail.com> >> wrote: >> >> > Nikita, >> > >> > The system property isn't really the problem, right? The problem is the >> > default behavior? >> > Do you suggest that the future behavior change will be added to the >> > release notes? >> > Can you add a proposed release note text to the ticket so that we are on >> > the same page about what will be announced? >> > >> > Also, should there be something like run-time warning for the operations >> > that will later become forbidden? >> > >> > About the 2.16 change. I agree with the default - makes sense. But can >> we >> > please keep a way to revert this? >> > I think just changing the default behavior but keeping the property is >> the >> > best. >> > >> > The problem is that there can be people that understand the behavior but >> > want to do that anyway. Say, I have an ATOMIC and TRANSACTIONAL caches >> in >> > my system, >> > and I need to change them at the same time. How would I do that after >> the >> > change is implemented? >> > >> > >> > Thinking about this, I believe a more aggressive change would be better >> - >> > but with a possibility to opt-out. >> > My proposal: >> > - Don't deprecate the property - revert the commit. >> > - Change the default of the property. >> > - Make sure the error message explains how to return the old behavior >> > (IGNITE_ALLOW_ATOMIC_OPS_IN_TX=true). >> > - Make sure this is mentioned in the release notes. >> > - Do this in 2.15, not 2.16. >> > >> > WDYT? >> > >> > >> > Sorry for diving deep into this - this is a breaking change that >> > potentially impacts many users, that's why I'm a bit anxious :) >> > >> > Thanks, >> > Stan >> > >> > > On 24 Oct 2022, at 21:25, Nikita Amelchev <namelc...@apache.org> >> wrote: >> > > >> > > Stanislav, >> > > >> > > 2.15: The system property will be deprecated. Release notes will >> > > contain warning info about deprecation and behavior in future >> > > releases. >> > > >> > > 2.16: The system property will be removed. All atomic operations >> > > within transactions will be forbidden. >> > > >> > > See merged PR: https://github.com/apache/ignite/pull/10327/files >> > > >> > > сб, 22 окт. 2022 г. в 17:42, Stanislav Lukyanov < >> stanlukya...@gmail.com >> > >: >> > >> >> > >> Hi all, >> > >> >> > >> Can someone please clarify what specific changes will be implemented >> in >> > 2.15 and 2.16? What will be in release notes in 2.15 and 2.16? >> > >> >> > >> Thanks, >> > >> Stan >> > >> >> > >>> On 18 Oct 2022, at 21:50, Nikita Amelchev <namelc...@apache.org> >> > wrote: >> > >>> >> > >>> Hi, Maksim. >> > >>> >> > >>> I think marking the issue as 'important' and filling out the release >> > >>> notes field is enough to get the attention of a release manager. >> > >>> >> > >>> вт, 18 окт. 2022 г. в 20:26, Maksim Timonin < >> timoninma...@apache.org>: >> > >>>> >> > >>>> Hi guys, >> > >>>> >> > >>>> We agreed here [1] that all deprecations must be noted within >> release >> > >>>> notes. Do we have an option to mark a jira ticket in such a way to >> > fill the >> > >>>> future release notes correctly? >> > >>>> >> > >>>> [1] >> https://lists.apache.org/thread/3ko0kjdv16o3oftsfh8z8nz0tyfvo13v >> > >>>> >> > >>>> On Mon, Oct 17, 2022 at 8:21 PM Anton Vinogradov <a...@apache.org> >> > wrote: >> > >>>> >> > >>>>> Ok, let's do this. >> > >>>>> And schedule the fix to the 2.16. >> > >>>>> >> > >>>>> On Mon, Oct 17, 2022 at 7:42 PM Alexei Scherbakov < >> > >>>>> alexey.scherbak...@gmail.com> wrote: >> > >>>>> >> > >>>>>> By placing the @Deprecated annotation on the property. >> > >>>>>> >> > >>>>>> пн, 17 окт. 2022 г. в 19:07, Anton Vinogradov <a...@apache.org>: >> > >>>>>> >> > >>>>>>> How can we deprecate this? >> > >>>>>>> >> > >>>>>>> On Mon, Oct 17, 2022 at 5:30 PM Alexei Scherbakov < >> > >>>>>>> alexey.scherbak...@gmail.com> wrote: >> > >>>>>>> >> > >>>>>>>> We can do breaking changes by following the approved >> procedure: 1) >> > >>>>>>>> deprecate in the next release 2) remove in the some release >> after >> > the >> > >>>>>>> next >> > >>>>>>>> >> > >>>>>>>> The ticket looks fine to me. >> > >>>>>>>> >> > >>>>>>>> пн, 17 окт. 2022 г. в 15:50, Anton Vinogradov <a...@apache.org>: >> > >>>>>>>> >> > >>>>>>>>> We MUST break this, of course! >> > >>>>>>>>> Atomic operations inside the transaction is a wrong and >> > unexpected >> > >>>>>>>>> behaviour and MUST be restricted for every user. >> > >>>>>>>>> >> > >>>>>>>>> On Mon, Oct 17, 2022 at 3:05 PM Julia Bakulina < >> > >>>>>> julia.bak...@yandex.ru >> > >>>>>>>> >> > >>>>>>>>> wrote: >> > >>>>>>>>> >> > >>>>>>>>>> Hi Team, >> > >>>>>>>>>> >> > >>>>>>>>>> I have found this ticket >> > >>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-8801 - >> > >>>>>>>>>> Change default behaviour of atomic operations inside >> > >>>>> transactions - >> > >>>>>>> in >> > >>>>>>>>>> backlog and created a PR with changes. The ticket relates to >> > >>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-2313. >> > >>>>>>>>>> During the review process it appeared that probably there is >> no >> > >>>>>> need >> > >>>>>>> in >> > >>>>>>>>>> this ticket as it includes the changes of the default API >> and we >> > >>>>>>> should >> > >>>>>>>>> not >> > >>>>>>>>>> break backward compatibility. >> > >>>>>>>>>> >> > >>>>>>>>>> Do we need these changes? Should the ticket be closed with >> > "won't >> > >>>>>>> fix"? >> > >>>>>>>>>> >> > >>>>>>>>>> Have a nice day, >> > >>>>>>>>>> Julia >> > >>>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> -- >> > >>>>>>>> >> > >>>>>>>> Best regards, >> > >>>>>>>> Alexei Scherbakov >> > >>>>>>>> >> > >>>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> -- >> > >>>>>> >> > >>>>>> Best regards, >> > >>>>>> Alexei Scherbakov >> > >>>>>> >> > >>>>> >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> Best wishes, >> > >>> Amelchev Nikita >> > >> >> > > >> > > >> > > -- >> > > Best wishes, >> > > Amelchev Nikita >> > >> > >> >
