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 >
