Igor, good point about "pluggable" collections, and Java has Collector interface for streams. Instead of replacing Maps with something, we can add overloads for advanced usage:
putAll(Iterable<Pair>) R getAll(Collector<T, A, R>) On Fri, Sep 10, 2021 at 3:07 PM Igor Sapego <isap...@apache.org> wrote: > I actually agree with Pavel, at least at putAll() part. We require a Map > from user > when we do not really need a Map in this method. What we really need here > is > an iterable collection of pairs. Can not see why user can not pass for > example an > array here. > > Now, when we talk about getAll() method it's more complicated, as in many > cases > I think a user would expect the returned collection to provide Map methods. > In C++ > you can deal with it by providing a method that takes a write iterator. > Using this > iterator we can put objects in any collection, provided by the user. Maybe > we can > achieve something similar using generics in Java, but I believe if we are > using this > approach then we still should provide simple method returning Map, because > to me > it looks like this is still going to be the most popular scenario. > > Best Regards, > Igor > > > On Fri, Sep 10, 2021 at 9:50 AM Pavel Tupitsyn <ptupit...@apache.org> > wrote: > > > 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 11:21 PM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > 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 confusing - it's a significant > risk. > > > Secondly, there is no standard Pair class, so we'll have to introduce a > > > custom one. That said, I would not change this API in Java. In other > > > languages, however, we can consider this. > > > > > > -Val > > > > > > On Thu, Sep 9, 2021 at 8:01 AM Alexei Scherbakov < > > > alexey.scherbak...@gmail.com> wrote: > > > > > > > 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 <ptupit...@apache.org>: > > > > > > > > > Igniters, > > > > > > > > > > I propose to replace Map with List<Pair> in getAll and invokeAll, > and > > > > > Iterable<Pair> 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 or some other place, instead of allocating a huge collection > and > > > > > performing unnecessary hashing. > > > > > > > > > > getAll returns a Map, but we don't know if the user code needs a > map > > or > > > > > just wants to iterate over the results, in which case Map is just > > > > overhead. > > > > > > > > > > > > > "allocating a huge collection" - > > > > This method is not intended for loading a huge number of entries. > > > > The allowed map size for the putAll should be limited to some > > reasonable > > > > value. > > > > > > > > Streaming loading should be addressed in a separate API similar to > > > > DataStream from Ignite 2. > > > > > > > > > > > > > > > > > > 2. Equality > > > > > getAll returns Map<K, V>, but in many cases, the map will be > useless > > > > > because K does not have proper equals()/hashCode() implementation, > so > > > > > map.get(key) does not work. > > > > > > > > > > > > > We shouldn't rely on user equals/hashCode while working with > key-value > > > API. > > > > Internally it uses binary representation of a user object for > > comparison > > > > purposes. > > > > The returned map implementation should work in the same way. > > > > > > > > > > > > > > > > > > Notes: > > > > > - It is not clear which Pair class to use yet - IgniteBiTuple or > > > > something > > > > > else. > > > > > - Ignite 3 won't deadlock due to putAll entry order, so we don't > have > > > to > > > > > worry about sorting. > > > > > > > > > > Thoughts, objections? > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > Alexei Scherbakov > > > > > > > > > >
