Hi, We recently had this issue opened about us not choosing the right access type for a mapped super class: https://hibernate.atlassian.net/browse/HHH-12938 . Hibernate currently base the access type decision on the sole placement of the @Id annotation, which, in the case of a @MappedSuperclass might not be defined (this is the OP's case). I closed the issue explaining what we do and pointing a workaround but the OP rightfully replied with the JPA spec saying "The default access type of an entity hierarchy is determined by the placement of mapping annotations on the attributes of the entity classes and mapped superclasses of the entity hierarchy that do not explicitly specify an access type". I'm wondering if we should also consider the @Column annotations placement if there is no @Id annotation. If the answer is that it's already fixed in 6, it's all good for me :). Thoughts? -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

The generated model of the MappedSuperclass? Because the one of the subclass is correct for sure. On Thu, Jan 10, 2019 at 12:44 PM andrea boriero <andrea(a)hibernate.org&gt; wrote: > I'm not sure I have fully understood the issue, the @Id may be not > defined in the MappedSuperclass but for sure it must be in the subclasses > extending it. > > I have tried and I can reproduce the issue only if I do not specify > any @Id annotation in the subclass, but as soon as I add the @Id to a > subclass of the MappedSuperclass the generated static metamodel is correct. > > > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet <guillaume.smet(a)gmail.com&gt; > wrote: > >> Hi, >> >> We recently had this issue opened about us not choosing the right access >> type for a mapped super class: >> https://hibernate.atlassian.net/browse/HHH-12938 . >> >> Hibernate currently base the access type decision on the sole placement >> of >> the @Id annotation, which, in the case of a @MappedSuperclass might not >> be >> defined (this is the OP's case). >> >> I closed the issue explaining what we do and pointing a workaround but >> the >> OP rightfully replied with the JPA spec saying "The default access type >> of >> an entity hierarchy is determined by the placement of mapping annotations >> on the attributes of the entity classes and mapped superclasses of the >> entity hierarchy that do not explicitly specify an access type". >> >> I'm wondering if we should also consider the @Column annotations >> placement >> if there is no @Id annotation. >> >> If the answer is that it's already fixed in 6, it's all good for me :). >> >> Thoughts? >> >> -- >> Guillaume >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >

Trying to make sure I understand.. so the report is just wrong? Or is there some difference in your model versus theirs? On Thu, Jan 10, 2019 at 2:22 PM andrea boriero <andrea(a)hibernate.org&gt; wrote: > yes also for the MappedSuperclass > > from: > > @MappedSuperclass > public abstract class AbstractCatalogEntity { > @Column( name = "CODE") > private String code; > > @Column( name = "NAME") > private String name; > } > > @Entity > public class CatalogEntity extends AbstractCatalogEntity { > @Id > private Long id; > } > > I obtained : > > @Generated(value = > "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor") > @StaticMetamodel(AbstractCatalogEntity.class) > public abstract class AbstractCatalogEntity_ { > > public static volatile SingularAttribute<AbstractCatalogEntity, String> > code; > public static volatile SingularAttribute<AbstractCatalogEntity, String> > name; > > public static final String CODE = "code"; > public static final String NAME = "name"; > > } > > @Generated(value = > "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor") > @StaticMetamodel(CatalogEntity.class) > public abstract class CatalogEntity_ extends > org.hibernate.userguide.model.AbstractCatalogEntity_ { > > public static volatile SingularAttribute<CatalogEntity, Long> id; > > public static final String ID = "id"; > > } > > > > > On Thu, 10 Jan 2019 at 11:52, Guillaume Smet <guillaume.smet(a)gmail.com&gt; > wrote: > > > The generated model of the MappedSuperclass? > > > > Because the one of the subclass is correct for sure. > > > > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero <andrea(a)hibernate.org&gt; > > wrote: > > > >> I'm not sure I have fully understood the issue, the @Id may be not > >> defined in the MappedSuperclass but for sure it must be in the > subclasses > >> extending it. > >> > >> I have tried and I can reproduce the issue only if I do not specify > >> any @Id annotation in the subclass, but as soon as I add the @Id to a > >> subclass of the MappedSuperclass the generated static metamodel is > correct. > >> > >> > >> On Thu, 10 Jan 2019 at 11:04, Guillaume Smet <guillaume.smet(a)gmail.com > > > >> wrote: > >> > >>> Hi, > >>> > >>> We recently had this issue opened about us not choosing the right > access > >>> type for a mapped super class: > >>> https://hibernate.atlassian.net/browse/HHH-12938 . > >>> > >>> Hibernate currently base the access type decision on the sole > placement > >>> of > >>> the @Id annotation, which, in the case of a @MappedSuperclass might > not > >>> be > >>> defined (this is the OP's case). > >>> > >>> I closed the issue explaining what we do and pointing a workaround but > >>> the > >>> OP rightfully replied with the JPA spec saying "The default access > type > >>> of > >>> an entity hierarchy is determined by the placement of mapping > annotations > >>> on the attributes of the entity classes and mapped superclasses of the > >>> entity hierarchy that do not explicitly specify an access type". > >>> > >>> I'm wondering if we should also consider the @Column annotations > >>> placement > >>> if there is no @Id annotation. > >>> > >>> If the answer is that it's already fixed in 6, it's all good for me > :). > >>> > >>> Thoughts? > >>> > >>> -- > >>> Guillaume > >>> _______________________________________________ > >>> 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 >

This is one of the cases (there are others) where we do not completely follow the JPA spec. TBH I'm not really sure how we would address this in an annotation processor, though granted my knowledge of those APIs is limited. But as I understand it we have to generate the metamodel class as we process the model class without knowledge of or access to other classes. Specifically here, we see the MappedSuperclasss first as it is a superclass and the compiler needs to process it first. I had planned on re-looking at this in 7 to offer a non-AP solution to metamodel generation. I don't think anything requires that we support this through an AP. There are other problems using an AP for this, namely it is extremely difficult to incorporate orm.xml info whether partial or complete. I guess a solution for now would involve somehow delaying the generation of the metamodel classes until the end of the AP cycle which (IIUC) would only really work with `proc:only` On Thu, Jan 10, 2019 at 6:29 AM Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: > The generated model of the MappedSuperclass? > > Because the one of the subclass is correct for sure. > > On Thu, Jan 10, 2019 at 12:44 PM andrea boriero <andrea(a)hibernate.org&gt; > wrote: > > > I'm not sure I have fully understood the issue, the @Id may be not > defined > > in the MappedSuperclass but for sure it must be in the subclasses > extending > > it. > > > > I have tried and I can reproduce the issue only if I do not specify > > any @Id annotation in the subclass, but as soon as I add the @Id to a > > subclass of the MappedSuperclass the generated static metamodel is > correct. > > > > > > On Thu, 10 Jan 2019 at 11:04, Guillaume Smet <guillaume.smet(a)gmail.com&gt; > > wrote: > > > >> Hi, > >> > >> We recently had this issue opened about us not choosing the right > access > >> type for a mapped super class: > >> https://hibernate.atlassian.net/browse/HHH-12938 . > >> > >> Hibernate currently base the access type decision on the sole > placement of > >> the @Id annotation, which, in the case of a @MappedSuperclass might > not be > >> defined (this is the OP's case). > >> > >> I closed the issue explaining what we do and pointing a workaround but > the > >> OP rightfully replied with the JPA spec saying "The default access > type of > >> an entity hierarchy is determined by the placement of mapping > annotations > >> on the attributes of the entity classes and mapped superclasses of the > >> entity hierarchy that do not explicitly specify an access type". > >> > >> I'm wondering if we should also consider the @Column annotations > placement > >> if there is no @Id annotation. > >> > >> If the answer is that it's already fixed in 6, it's all good for me :). > >> > >> Thoughts? > >> > >> -- > >> Guillaume > >> _______________________________________________ > >> 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 >