> 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 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? There would be some rough edges (what would org.hibernate.Session#getIdentifier return, the embedded id or the idclass? What would Session.load accept? What would be the declared type of the ID in JPA Criteria?). But that could be a valuable feature for people who really want composite IDs. And it could solve the caching problem. However, if we need to solve the caching problem in ORM 5 and are not in a position to declare that caching isn't supported for such identifiers... then we'll have to work on some hack in ORM 5. So maybe it's not a priority in ORM 6. Yoann Rodière Hibernate Team yo...@hibernate.org On Thu, 5 Dec 2019 at 14:16, Steve Ebersole <st...@hibernate.org> wrote: > A few things... > > On Thu, Dec 5, 2019 at 1:17 AM Yoann Rodiere <yo...@hibernate.org> 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 particular when using IDs in URL >> paths or in JSON content. >> > > 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 ;) > FWIW however, JPA does not define support for @EmbeddedId with > a @ManyToOne. So in that sense we'd be "ok" simply saying "ok, we support > mapping those, but they cannot be cached" if we need to go that route. > > We already support a form of loading an entity with MapsId using the basic > form of the associated id if the associated entity as just a simple id. > It's not a stretch to extend that to composite ids I think which would be a > good feature. Consider: > > @Entity > public class Person { > @Id String ssn; > > ... > } > > @Entity > public class MedicalHistory { > @Id > @OneToOne > @JoinColumn(name="FK") > Person patient; > > ... > } > > You can load a MedicalHistory here using the Person id. E.g. ` > session.get( MedicalHistory.class, "123-45-6789" );` > > If you consider a case like: > > @Entity > @IdClass(EmployeeId.class) > public class Employee { > @Id String firstName > @Id String lastName > > ... > } > > public class DependentId { > String name; > EmployeeId emp; > } > > @Entity > @IdClass(DependentId.class) > public class Dependent { > @Id String name; > @Id > @JoinColumns({ > @JoinColumn(name="FK1", referencedColumnName="firstName"), > @JoinColumn(name="FK2", referencedColumnName="lastName") > }) > @ManyToOne Employee emp; > > ... > } > > It would be nice to allow loading a Dependent like: `session.load( > Dependent.class, > new Object[] {"Steve","Ebersole"} );` The trouble there is the ordering > of the values compared to the attribute order. > > This is all beyond the original question, but your point about loading > these made me think about this. Ofc serializing does not disassemble, so > this is a moot point in regards to that. For JSON, depends on your > marshalling > > > For these IDs to make sense, we would need to force users to define a >> separate, association-free class (using @IdClass?) to represent the >> "serializable" form of the embedded ID, which would also be used in >> Session.find() et. al. This would probably help when it comes to caching, >> too. >> > > 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? > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev