Additional Modeling Abilities
In this first article we will illustrate some of the ways that JPA 2.0 will increase the flexibility that you have as a Java developer to model your objects. This includes lifting some of the constraints that were placed upon the model in version 1.0, as well as providing access to additional features and creating a more natural and self-documenting domain model.
Flexible Access Modes
Sometimes the noblest of causes will still produce casualities (no political commentary intended!), but this was borne out by the attempts to make JPA very default-driven. The cost of trying to default the way that JPA implementers (commonly referred to as persistence providers, or simply providers) access the state of an entity is that it became very difficult to actually have an exception from the default without stumbling into complexity. The result was that there was no way to mix accessing the state through the instance variables or through property methods within the same entity hierarchy, or even across an owning entity and the objects it may have embedded.
A solution has been found, however, to allow an entity in the midst of a hierarchy to declare that its state be accessed differently from the other classes in the hierarchy. The access mode for a class can be set by placing an @Access annotation on it, causing the default access mode in effect for the hierarchy to be locally overridden. The value attribute of the @Access annotation specifies either FIELD or PROPERTY to determine whether field-based or property-based access is to be undertaken by the provider.
This annotation will be useful for more than just the case of using a different access mode for an entity in a hierarchy. It will also be useful to solve the problem mentioned above, where an entity has an embedded object and the embeddable happens to have been mapped using a different access type than the owning entity. This is particularly helpful if the embeddable type is embedded by multiple entity types with different access types. The current specification all but rules this out.
Another case when this feature will be useful is when you need to perform some kind of simple transformation to the data when reading from or writing to the database. In general you will want the provider to access the data using FIELD access, but in this case you will need to use a get/set method pair to perform the transformation.