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.
Please
Hello all,
we've released Hibernate ORM version 5.4.10.Final !
For details:
https://in.relation.to/2019/12/05/hibernate-orm-5410-final-release/
Thanks all!
Andrea
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mai
>
> > 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?
>
> Ther
Please do not push anything to master branch.
Thanks,
Andrea
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 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 not
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 a
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
interesting
