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