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
