Completely agree. Also locks acquisition related futures should be renamed.
On Thu, Dec 21, 2017 at 8:21 AM, ALEKSEY KUZNETSOV
wrote:
>
> for renaming +1
>
>> 21 дек. 2017 г., в 5:25, Dmitriy Setrakyan
>> написал(а):
>>
>> Will this renaming introduce any issues with supporting previous version
for renaming +1
> 21 дек. 2017 г., в 5:25, Dmitriy Setrakyan написал(а):
>
> Will this renaming introduce any issues with supporting previous versions?
>
>> On Wed, Dec 20, 2017 at 9:10 AM, Yakov Zhdanov wrote:
>>
>> How about we explain it in javadocs and properly document on wiki? Guys, I
Will this renaming introduce any issues with supporting previous versions?
On Wed, Dec 20, 2017 at 9:10 AM, Yakov Zhdanov wrote:
> How about we explain it in javadocs and properly document on wiki? Guys, I
> would do this at some point when there is no another bigger issue in Ignite
> =)
>
> --Y
How about we explain it in javadocs and properly document on wiki? Guys, I
would do this at some point when there is no another bigger issue in Ignite
=)
--Yakov
ly obfuscating for new contributor, since in fact they are not
> adapters for something but abstract superclasses.
>
> 2017-12-20 18:18 GMT+03:00 Alexey Goncharuk :
>
> > Igniters,
> >
> > As I review transaction-related PRs and communicate with other fellow
> > Ignit
review transaction-related PRs and communicate with other fellow
> Igniters, I realized that our transaction classes naming became
> inconsistent and almost impossible to explain to a new contributor. A few
> examples:
>
> 1) We have a GridNearTxLocal class, but Near in the name doe
*Request/Response.
Best Regards,
Ivan Rakov
On 20.12.2017 18:18, Alexey Goncharuk wrote:
Igniters,
As I review transaction-related PRs and communicate with other fellow
Igniters, I realized that our transaction classes naming became
inconsistent and almost impossible to explain to a new contri
+1
On Wed, Dec 20, 2017 at 6:18 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Igniters,
>
> As I review transaction-related PRs and communicate with other fellow
> Igniters, I realized that our transaction classes naming became
> inconsistent and almost impos
Igniters,
As I review transaction-related PRs and communicate with other fellow
Igniters, I realized that our transaction classes naming became
inconsistent and almost impossible to explain to a new contributor. A few
examples:
1) We have a GridNearTxLocal class, but Near in the name does not