What is the purpose of AccessType.FIELD, AccessType.PROPERTY and @Access

Question

I just want to know what is the difference between all these annotations. Why are we using these... means they have no effect especially field level and property level.

And what is the purpose of using mixed level annotation like:

@Entity
@Access(AccessType.FIELD)
class Employee {
    // why their is a field level access 
    private int id;

    // whats the purpose of transient here
    @Transient                               
    private String phnnumber;

    // why its a property level access
    @Access(AccessType.property)             
    public String getPhnnumber() {
        return "1234556";
    }

}

what exactly this class says?

Boswall

See also excellent comparation discussion: #595097 – Dudden

Answer 1

By default the access type is defined by the place where you put your mapping annotations. If you put them on the field - it will be AccessType.FIELD, if you put them on the getters - it will be AccessType.PROPERTY.

Sometimes you might want to annotate not fields but properties (e.g. because you want to have some arbitrary logic in the getter or because you prefer it that way.) In such situation you must define a getter and annotate it as AccessType.PROPERTY.

As far as I remember, if you specify either AccessType.FIELD or AccessType.PROPERTY on any of the entity fields / methods you must specify the default behaviour for the whole class. And that's why you need to have AccessType.FIELD on the class level (despite that AccessType.FIELD is the default value.)

Now, if you wouldn't have @Transient on the phnnumber field, the JPA would provide you with a 3 columns table:

• id,
• phnnumber,
• getphnnumber.

That's because it would use AccessType.FIELD for all of the entity fields (id and phnnumber) and, at the same time, it'd use AccessType.PROPERTY for your getter (getPhnnumber()).
You'll end with phone number mapped twice in the database.

Therefore, the @Transient annotation is required - it means that the entity won't store the value of the field in the underlying storage but the value returned by your getter.

Subsistent

The default is not FIELD. The access type is FIELD if you place mapping annotations on fields, and it's PROPERTY if you place mapping annotations on getters. And all the entity hierarchy must be coherent in the mapping annotation placement: always on fields, or always on getters, but not mixed. – Solly

You're right - the default is dependent on where the @Id annotation is located. About the mixing - you're referring only to the id annotation or to the fact that you can't mix the property / field access at all in the entity hierarchy? – Subsistent

If you don't explicitely specify access type, the JPA spec says that all the mapping annotations in the hierarchy must be placed either on fields, or on getters. What happens if you don't respect the rule is not specified though. Hibernate looks up where the Id annotation is, and if it's on field it ignores all the annotations on getters (and vice-versa), but this is Hibernate-specific. The behavior in such a case is undefined (that's what the spec says). – Solly

I could swear I've read about @Id in "Pro JPA 2.0: Mastering the Java Persistence" but I just checked the spec and it really doesn't talk about the Id at all; just about mapping annotations you've mentioned. Thanks for the clarification JB! – Subsistent

Ok, I just found out that in the book it was @Id because it was the only mapping annotation in the example... – Subsistent

"As far as I remember, if you specify either AccessType.FIELD or AccessType.PROPERTY on any of the entity fields / methods you must specify the default behaviour for the whole class." - Why should one specify on class level? – Lem

very nice how this works with kotlin ? – Slype

Maybe a little late but @PiotrNowicki maybe you could remove the part about the location of the id annotation from your answer if you came to the conclusion that it does not matter. – Coherent

@Coherent thanks for suggestion - it's over 10 years old, but I totally agree that it's worth to avoid the confusion :-) Cheers! – Subsistent