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
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
Let's clarify column order and nullable columns handling.
Our current API (Table, KvView) does not rely on column order in
user-provided tuples.
Therefore, two tuples with the same set of columns and equal values for
every column may be considered equal.
Tuple a = Tuple.create().set("name",
Sounds very reasonable to me.
+1
Though the default comparator should be implemented very carefully
as we had issues with comparison of binary objects in 2.x
Best Regards,
Igor
On Thu, Sep 9, 2021 at 4:04 PM Pavel Tupitsyn wrote:
> Igniters,
>
> Tuple in Ignite 3.x is a replacement for
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
