Hi Steve,
I like your ideas about loading an entity with multiple ID attributes
without @IdClass. It's much nicer than passing an instance of the entity
with ID attributes initialized to Session#get.
Getting back to the cache issue -- it sounds like disassembling the ID is
worth pursuing.
>
> > JPA does not allow mixing of @IdClass and @EmbeddedId. But I think
> that's a valid option. In fact in our original work on 6 where we
> completely replaced the mapping model (persisters) i had added support for
> this. We could add an improvement to pull this feature to 6 proper?
>
>
> I disagree to an extent here. Assuming I think composite ids are a good
idea anyway (I dont) then I actually think this is the most natural way to
model this. I personally think JPA's MapsId is the monstrosity here ;)
Fair enough. @MapsId definitely has its own set of problems.
> JPA does
A few things...
On Thu, Dec 5, 2019 at 1:17 AM Yoann Rodiere wrote:
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
> deserialize such ID without a session, in
I think Sanne meant relying on equals/hasCode of the embeddable itself,
which we do not do as you pointed out.
On Wed, Dec 4, 2019 at 5:19 PM Gail Badner wrote:
> Hi Sanne,
>
> By default, the cache key is of type CacheKeyImplementation [1]. As long as
> a composite key is a ComponentType (not
This all sounds s familar. But I was not able to find the Jira.
Seems to be there was a reason that we don't disassemble the id, though
that reason escapes me atm. That does seem like the logical thing to do.
Regardless of why I think we may have decided not to, it would still be
> 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
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.
10 matches
Mail list logo
