+1 to ban Streams usage.
> 9 сент. 2021 г., в 02:59, Valentin Kulichenko
> написал(а):
>
> Pavel,
>
> Quite frankly, I think we used to lean into performance too much. We
> generally preferred it over data consistency, project modularity and code
> readability. Performance, of course, plays
To be honest, Pavel, your benchmark is not quite correct. Please, rewrite
it using BlackHole
чт, 9 сент. 2021 г. в 10:28, Nikolay Izhikov :
> +1 to ban Streams usage.
>
>
>
> > 9 сент. 2021 г., в 02:59, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> написал(а):
> >
> > Pavel,
> >
> > Quit
Few words about the topic.
There is a disease, quite common in the java community -- it is called the
streamosis.
But, to be honest, afear of streams is also not good.
As for me, sometimes rewriting code completely with simple loops often
makes it more readable, understandable and usually faster.
Hello!
-1 Let's not ban Java Streams, for the reasons already listed.
Regards,
--
Ilya Kasnacheev
чт, 9 сент. 2021 г. в 10:59, Ivan Daschinsky :
> Few words about the topic.
> There is a disease, quite common in the java community -- it is called the
> streamosis.
> But, to be honest, afear o
>> 2. In languages with proper async support (async-await, etc.), we can
skip sync API altogether.
It sounds pretty strange, as for me. Usually you cannot mix both functions
easily, it is called blue-red functions problem [1]
In python you definitely cannot do sync over async, for example
(principa
Ivan,
> Pavel, is it really true, that in .NET sync versions of libraries and
tools
> are completely eliminated?
Far from being eliminated, but there is a movement in this direction.
For example, HttpClient [1] only provides async variants for most of the
methods.
Exposing sync wrappers for asyn
>> You can mix them easily.
This is far from easily (you have already mentioned continuation problem),
but for i.e. in python it is absolutely not.
For kotlin it is a little bit easier, but also not fluent and a little bit
ugly.
чт, 9 сент. 2021 г. в 11:37, Pavel Tupitsyn :
> Ivan,
>
> > Pavel, i
Talked to Ivan in private, and came up with the following per-language
summary:
* Java: sync and async
*. NET: only async
* Python: sync and async
* JavaScript: only async (sync is not possible)
Thin clients in other languages are to be discussed.
On Thu, Sep 9, 2021 at 11:49 AM Ivan Daschinsky
And what about C/C++? There are so many options for them...
чт, 9 сент. 2021 г. в 13:00, Pavel Tupitsyn :
> Talked to Ivan in private, and came up with the following per-language
> summary:
>
> * Java: sync and async
> *. NET: only async
> * Python: sync and async
> * JavaScript: only async (syn
Hi, folks.
Unfortunately, a quite severe bug found in pyignite since 0.4.0 was found
[1]. Fortunately, it is already fixed. Also there are also a few bugs
already fixed.
I propose to prepare the next minor release. Branch was already cut and
commits were cherry-picked [3].
If there are no object
TC build of release branch --
https://tc.sbt-ignite-dev.ru/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6130289
чт, 9 сент. 2021 г. в 13:40, Ivan Daschinsky :
> Hi, folks.
>
> Unfortunately, a quite severe bug found in pyignite since 0.4.0 was found
> [1]. Fortunately, it is alread
+1 to release ASAP.
> 9 сент. 2021 г., в 13:43, Ivan Daschinsky написал(а):
>
> TC build of release branch --
> https://tc.sbt-ignite-dev.ru/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6130289
>
> чт, 9 сент. 2021 г. в 13:40, Ivan Daschinsky :
>
>> Hi, folks.
>>
>> Unfortunate
Well, fortunately we do not provide a C client if you don't consider ODBC
as one so we should not think about it. For C++ I believe we should use
standard std::future+std::promise for async, but still can provide sync
methods,
built on top of async methods. There is no continuation problem in C++ A
Igor, and what about C++20 and coroutines [1]
[1] -- https://en.cppreference.com/w/cpp/language/coroutines
чт, 9 сент. 2021 г. в 14:12, Igor Sapego :
> Well, fortunately we do not provide a C client if you don't consider ODBC
> as one so we should not think about it. For C++ I believe we should
Ivan,
We are not going to adopt C++20 in the near future, as new standards
are not adopted as fast in C++ world and if we'd do that most probably
almost none of our users could use our client.
But yeah, if we'd use coroutines, I'd probably suggest that we only
provide the async API.
Best Regards
Igniters,
I propose to replace Map with List in getAll and invokeAll, and
Iterable in putAll APIs of Ignite 3.x KeyValueView.
1. Performance
putAll simply iterates over the map, we can easily accept Iterable instead.
Iterable can be implemented over anything, it can lazily read data from a
file o
Igniters,
Tuple in Ignite 3.x is a replacement for BinaryObject in Ignite 2.x.
Let's discuss equality and sorting.
- We have multiple Tuple implementations, and our API allows custom,
user-defined Tuples as well (which can be useful for performance when
bridging Ignite with another system or impo
Pavel,
I think the current API looks more natural compared to your proposal.
-1 from my side, see comments below.
чт, 9 сент. 2021 г. в 15:38, Pavel Tupitsyn :
> Igniters,
>
> I propose to replace Map with List in getAll and invokeAll, and
> Iterable in putAll APIs of Ignite 3.x KeyValueView.
I've checked Guava's feature list and came to a conclusion it's usefulness
has been diminished by switching to base java 11.
-1 for general use, but we can use some code parts then needed.
ср, 8 сент. 2021 г. в 14:09, Вячеслав Коптилин :
> -1
> I am leaning toward -1 because of vulnerability
Folks, Denis,
I disagree with you that the changes are ready. They are not compiling
and require additional manual tests. I see the following reasons:
- The major version of dependencies are changed;
- Handling of error codes output changed;
- For a new module developed in 2021 the old version of
+1
On Thu, 9 Sept 2021 at 14:08, Nikolay Izhikov wrote:
>
> +1 to release ASAP.
>
> > 9 сент. 2021 г., в 13:43, Ivan Daschinsky написал(а):
> >
> > TC build of release branch --
> > https://tc.sbt-ignite-dev.ru/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6130289
> >
> > чт, 9 сен
Maxim,
I'm good with your plan. Thanks for sharing the details. Let's follow the
plan and release 2.11 asap.
-
Denis
On Thu, Sep 9, 2021 at 1:02 PM Maxim Muzafarov wrote:
> Folks, Denis,
>
>
> I disagree with you that the changes are ready. They are not compiling
> and require additional manua
How do we handle the "equality" part in 2.x? The same problem exists there
as well, but we still somehow return a Map.
Generally, I like Pavel's ideas, but there are a couple of issues with
them. Firstly, Java developers are really used to maps in this context.
Introducing something else might be
Val, Alexei - thanks for your replies.
Let's keep the Map approach then.
Regarding tuple equality - there is another thread [1], please have a look.
https://lists.apache.org/thread.html/r9ed68cd515bffab6df821bbeccb8e44d0e5536000e5e7dd05bd87017%40%3Cdev.ignite.apache.org%3E
On Thu, Sep 9, 2021 at
24 matches
Mail list logo
