> Perhaps the best solution is to constrain this, and warn that such a
> model is not a good fit for caching?
This. Embedded IDs containing an association are a monstrosity anyway, and
lead to problems even on the user side.
E.g. you can't serialize (to a String, JSON, ...) and more importantly
de
Hi Sanne,
By default, the cache key is of type CacheKeyImplementation [1]. As long as
a composite key is a ComponentType (not a CustomType),
CacheKeyImplementation#equals and #hashCode uses ComponentType#equals and
#hashCode, not the custom implementation of the embeddable class methods.
IIRC, a
Hi Gail,
going for a disassembled ID would seem logical, but we'll need some
special care to deal with custom implementations of equals/hashcode.
Clearly a composite ID object would require the users to implement a
custom equals(); going for a solution based on a disassembled ID we
would need to
When an entity is cached with a composite ID containing a many-to-one
association, the cache key will contain the many-to-one associated entity.
If the associated entity is not enhanced, then it could be an uninitialized
proxy.
I've created a test case [1] that illustrates this using Infinispan. T
