Well, looks like BinaryIdentityResolver is a dead-end as well. Though
the interface still exists, there is no way to configure a custom
implementation for a particular type. Despite issues IGNITE-4889,
IGNITE-4919, IGNITE-4977 and discussion in [1] stating it should be
removed or is deprecated, the
Hello!
I don't think there is a better solution. Ignite uses binary representation
of key to build its B+ tree. If some non-transient field is different then
it is a different key, even if it is not used in hashCode.
Regards,
--
Ilya Kasnacheev
пт, 21 июн. 2019 г. в 14:48, Axel Faust :
> Mayb
Maybe the term "complex" is a bit misleading. I used it to differentiate
the kind of composite key used from the trivial, e.g. String/Long keys
that might be used for simple entity lookups. In my immediate case, the
key is a small immutable object with two hash relevant fields + one
non-hash releva
Hello!
Usually it is not wise to have large complex keys, especially ones that you
do not control. Can cause all sorts of issues.
You can declare your key Externalizable, though, and have control over its
marshalling. That, or Binarylizable. Then you get to decide how everything
is processed.
R
Hello,
I have been working on integrating Apache Ignite as a distributed
caching layer in the open source edition of the Alfresco Content
Services product. As this would be an extension, I don't have full
control over the kinds of keys used in cache operations. One default
cache in particular is u
