The general rule I always have in mind for breaking changes - there should be a
way to fallback to the old behavior.
Even if the old behavior is unreasonable, and people shouldn't rely on it, you
should let them acknowledge they are in the wrong - but continue to operate as
they used to.
And in
Hi,
Please, imagine a possible case:
1. Atomic cache exists for a function that doesn't require strong
guarantees, like audit or counter.
2. Put for such cache is implemented as a processor that is built-in to a
spring annotation (some meaningful method is annotated with it).
3. The meaningful met
Changing the atomic caches in a transaction is really weird, so I would
remove the property as well and retain only the safe behavior.
If you want to update an atomic cache, do it before or after a transaction.
пт, 28 окт. 2022 г. в 13:06, Maksim Timonin :
> Hi, all!
>
> In private discussion wit
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 ch
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
>> WDYT?
+1
On Tue, Oct 25, 2022 at 11:40 AM Stanislav Lukyanov
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
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 announce
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/ign
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 wrote:
>
> Hi, Maksim.
>
> I think marking the issue as 'important' and filling out the rele
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 :
>
> Hi guys,
>
> We agreed here [1] that all deprecations must be noted within release
> notes. Do we hav
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 Vi
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 :
>
> > How can we deprecate this?
> >
> > On Mo
By placing the @Deprecated annotation on the property.
пн, 17 окт. 2022 г. в 19:07, Anton Vinogradov :
> 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:
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.
>
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 :
> We MUST break this, of course!
> Atomic operations inside the transaction i
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
wrote:
> Hi Team,
>
> I have found this ticket https://issues.apache.org/jira/browse/IGNITE-8801 -
> C
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
17 matches
Mail list logo
