Maybe we can return user objects in the result? I suggest replacing Set/Map with a List in InternalTable because we don't need them actually. Uniqueness is not the issue. We can iterate over Set/Map, which we got from a user, and enumerate the keys, then put user objects back to the result based on our enumeration. This will require an order guarantee from the protocol, that the results are returned in the same order the keys are passed into the request.
On Mon, Sep 13, 2021 at 3:30 PM Andrey Mashenkov <andrey.mashen...@gmail.com> wrote: > Pavel, > > 1. Comparator introduces an ordered relation, but we need only equality > (e.g. Objects.deepEquals). > Ok, we can implement some orders for basic types adding complexity to cast > and compare for all the values. > > 2. Hashcode calculation will require iterating over all the columns. Most > likely iteration order is important, but using TreeMap in Tuple will help > here. > Log(n) access and iteration is an acceptable trade-off. > > 3. The challenge here is to make getAll operation return compatible > results even with all of mentioned above. > Shortly, we must fail an operation if some key has a missed column(s). > > Assume, there is a schema with a key of (col1, col2) where col2 is > nullable. > So, col2 may be omitted and key(col1) is a valid key and get(key(col1)) > will return the same result as get(key(col1, null)). > But getAll operation will return a Map contains key(col1, null) and > key(col1) will never match with key(col1, null). > > > On Thu, Sep 9, 2021 at 4:04 PM Pavel Tupitsyn <ptupit...@apache.org> > wrote: > >> 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 importing the data from somewhere). >> - We don't have equals()/hashCode() overrides, so it is not possible to >> compare tuples or put them into a Map. >> >> Proposal: >> - Add public TupleComparator implements Comparator<Tuple>, based on the >> tuple contents (column names and values) >> - Implement common TupleComparator#hashCode(Tuple t) method that combines >> hash codes of column names and values >> - Implement equals(), hashCode(), and Comparable on all built-in tuples, >> delegate the logic to TupleComparator >> - Make Tuple extend Compable >> >> This way we cover all sorting/comparing/mapping scenarios for built-in >> tuples and provide reusable code for third-party implementations. >> >> Thoughts? >> > > > -- > Best regards, > Andrey V. Mashenkov > -- Best regards, Andrey V. Mashenkov
