Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Complicated MappedSuperclass/AccessType question

Hi Laird,

The behavior you describe is indeed intentionally implemented that way in EclipseLink as this is also our interpretation of the spec as well (and we confirmed with direct discussions with members of the spec committee beforehand).

Cheers,
Guy


On 16/08/2011 11:37 PM, Laird Nelson wrote:
On Tue, Aug 16, 2011 at 6:06 PM, Laird Nelson <ljnelson@xxxxxxxxx> wrote:
What is the expected behavior in the following case?

I have a mapped superclass annotated with @Access(AccessType.FIELD).

It defines several fields and column mappings.

It features a private long id field, but it is entirely unannotated:

  private long id;

Then there is this:

@Access(AccessType.PROPERTY)
@Id
@GeneratedValue
@Column(name = "id")
public long getId() {
  return this.id;
}

public void setId(final long id) {
  this.id = id;
}

Next, I have an entity that extends this mapped superclass which is as unannotated as possible.

I should point out here that section 2.3.2 of the spec says:

"This explicit access type specification does not affect the access type of other entity classes or mapped superclasses in the entity hierarchy."

Then it says:

"Persistent state inherited from superclasses is accessed in accordance with the access types of those superclasses."

So that implies that my subclass should get the default access type, which is FIELD.

In Hibernate (not EclipseLink) I'm seeing the subclass get "switched over" to PROPERTY access.  This seems like a violation to me.  EclipseLink and OpenJPA show no such problems.  I am at a loss to know what the proper behavior is here.

 
  Obviously it features an @Entity tag, but most notably it does not declare an id field or override (yet) the getId() method.

It's my understanding that only for the id property should the getter/setter pair be used; every other field defined in either the mapped superclass or its entity child should use FIELD access.

...mainly because the subclass @Entity does not declare ANY @Access annotations anywhere, and so should pick up the default algorithm as described in section 2.3.1.  Again, I think EclipseLink gets this right, but I frankly would like the EclipseLink developers to weigh in here, as I trust their track record at interpreting the specification more than that of the Hibernate crew.  I've never seen a serious EclipseLink specification violation, so I'm hoping that this is (yet another) case where Hibernate gets it wrong, but I'm not sure.

Thanks.  The related Hibernate "user forums" post--I use the term guardedly--is over here: https://forum.hibernate.org/viewtopic.php?f=1&t=1012254

Best,
Laird
_______________________________________________ eclipselink-users mailing list eclipselink-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Back to the top