Create the issue and use the 'jandex-binding' version in Jira On Tue, Jan 12, 2016 at 5:57 AM Sanne Grinovero <sa...@hibernate.org> wrote:
> +1 this is a very common mistake for beginners. > > But I'm with Hardy in not trying to shoehorn such support in our > current metadata handling, but rather to keep it in mind when moving > it all to Jandex. (how to remember that?) > > On 12 January 2016 at 11:49, Hardy Ferentschik <ha...@hibernate.org> > wrote: > > Hi, > > > >> Would it be feasible to raise a warning or error in cases where > >> mapping annotations are given on an element not matching the default > >> access type for that entity and @Access has not been given explicitly > >> either? > > > > Sure, but I think it would need some doing. AFAIR the code determines > the access type > > and from then on just reflects on either fields or methods. Maybe as a > performance > > optimisation as well. Not sure. I agree having some warning for the case > you describe > > is a good idea, but don't expect this to be a one lines in the code. > > > > That said, things would be easier with Jandex. There it would be easier > to determine > > inconsistent configuration. I seem to vaguely recall that I might even > have done though > > when working in the metamodel branch. > > > > Personally I'd probably address this in conjunction with a re-write of > the mapping code > > and switch to Jandex. I think that is still somewhere on the horizon. > > > > If not, it is for sure feasible, just take quite some effort. > > > >> The most common case of this issue which I saw several times happen is > >> where @Id is given at the field level but some other mapping > >> annotations are given on property getters > > > > Right, that's a usual mistake. > > > >> for those not super-deep into the details of access type retrieval. > > > > I don't think you need to be super-deep into ORM/JPA to understand that. > > There are warnings and notes about this everywhere. > > > >> A warning might help them. > > > > For sure, but as said, I'd tackle this as part of a bigger refactoring. > > > > --Hardy > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
