Here is what I proposes in the documentation in the section discussing composite identifiers: <note> <para> Technically a composite identifier can be made up of just a single persistent attribute. </para> <para> The restriction that a composite identifier has to be represented by a "primary key class" is a JPA restriction. Hibernate does allow composite identifiers to be defined without a "primary key class", but use of that modeling technique is deprecated and not discussed here. </para> </note> On Mon, Aug 3, 2015 at 10:30 AM Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I am thinking we should start to soft-deprecate[1] the historical feature > of embedded composite identifiers. This is the feature that allowed an > entity to define a composite identifier without any kind of "pk class" > (EmbeddedId/IdClass): > > @Entity > public class MyEntity { > @Id > public Integer key1; > @Id > public Integer key2; > ... > } > > The you'd always have to instantiate the entity to deal with its > identifier. For example, to load such an entity: > > MyEntity id = new MyEntity(1,2); > MyEntity it = session.get( MyEntity.class, id ); > > Between EmbeddedId and IdClass there are better alternatives to document. > > Thoughts? > > [1] - By "soft-deprecate" I mean remove discussion of it from the > documentation, and don't really push it. > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

FWIW, that's one of the mapping patterns I always found awkward, so +1 for deprecating it from me. What would be the strategy, though? Deprecate in 5 and remove in 6? 2015-08-03 17:46 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > I remember loving this feature. > Composite keys are very common in databases I worked with, while > loading by ids seems to be quite uncommon in my coding style as I > don't remember knowing how to do that, nor that this ignorance ever > bothered me :) > > +1 anyway, that's just to give some perspective. > > On 3 August 2015 at 16:36, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > Here is what I proposes in the documentation in the section discussing > > composite identifiers: > > > > > > <note> > > <para> > > Technically a composite identifier can be made up of just a > > single persistent attribute. > > </para> > > <para> > > The restriction that a composite identifier has to be > > represented by a "primary key class" is > > a JPA restriction. Hibernate does allow composite identifiers > > to be defined without a > > "primary key class", but use of that modeling technique is > > deprecated and not discussed here. > > </para> > > </note> > > > > > > > > > > On Mon, Aug 3, 2015 at 10:30 AM Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > > > >> I am thinking we should start to soft-deprecate[1] the historical > feature > >> of embedded composite identifiers. This is the feature that allowed an > >> entity to define a composite identifier without any kind of "pk class" > >> (EmbeddedId/IdClass): > >> > >> @Entity > >> public class MyEntity { > >> @Id > >> public Integer key1; > >> @Id > >> public Integer key2; > >> ... > >> } > >> > >> The you'd always have to instantiate the entity to deal with its > >> identifier. For example, to load such an entity: > >> > >> MyEntity id = new MyEntity(1,2); > >> MyEntity it = session.get( MyEntity.class, id ); > >> > >> Between EmbeddedId and IdClass there are better alternatives to > document. > >> > >> Thoughts? > >> > >> [1] - By "soft-deprecate" I mean remove discussion of it from the > >> documentation, and don't really push it. > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >