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 > > > > > >
