Denis,
I still feel that redirecting yet another notification source to dev list
without discussion with the Community is not right way to go. Especially when
significant efforts were spent to keep the list clean. I will start a
discussion.
> On 6 Aug 2021, at 22:46, Mauricio Stekl wrote:
>
A side note. Actually “Ignition” naming always confused me. I think about it as
some fancy named API entry point for Ignite. Perhaps it is a good moment to
revisit naming.
> On 8 Jul 2021, at 07:09, Valentin Kulichenko
> wrote:
>
> Hi Pavel,
>
> I don't think we will need the pure embedded
Folks,
I suppose we should rollout voting regarding abbreviations in Ignite 3.
BTW, are you actually aware of any other project defining something similar to
our abbreviations?
Sent from my iPhone
> On 23 Jun 2021, at 14:53, Nikita Ivanov wrote:
>
> What's worked for countless companies is
Zhenya, Dmitriy,
>>> hi Dmitriy, Ivan Pavlukhin suggest to exclude IGNITE-12061 from 2.7.6, i
>>> have no clue - why,
The reason here is a lack of time to ensure that everything is fine there. The
patch is valuable but not so trivial. Honestly, I find it wrong to merge a
changes I am not sure
Ivan F.,
Agree with referring tickets in @Ignore annotation.
Currently I have no access to a computer. Will be able to look at updated PR
next week.
Sent from my iPhone
> On 14 May 2019, at 10:55, Ivan Fedotov wrote:
>
> Ivan P.,
> I managed with IgniteConfigVariationsAbstractTest - now
Hi Anton,
Meanwhile can we extend a feature description from a user point of view? It
would be good to provide some use cases when it can used.
The thing that is yet understood by me is a conflict resolving. E.g. in systems
inspired by Dynamo (sorry that no references, writing from phone)
Hi Saikat,
It is good that we agreed how property in question should be configured. But I
worry about the following. If the PR merged it will not contain a user value
yet because an introduced property is not used. Consequently we must start
using that property before a next AI release. Just
Sergey,
There are couple of things which should be addressed:
1. Unnecessary deserialization.
2. Inconsistent behavior.
3. Unclear documentation.
Deserialization is not free and in my mind should be avoided where possible. I
think that if some feature (like interceptors) requires
