Mike has posted 2 posts at DZone. View Full User Profile

Looking Forward To JPA 2.0 - Part 2

06.03.2008
| 51178 views |
  • submit to reddit

In the second installment of this series of sneak peeks at JPA 2.0, I am making good on my promise to tell you a little about some of the new additions to the suite of object-relational mappings standardized in JPA. I must still retain my disclaimer from the first article (see “Looking Forward to JPA 2.0 – Part 1”), however, and say that the spec is not final, so none of what is included in this article has been fully reified.

The new object-relational mapping features fall into two main categories:
a) expand the modeling options that can be mapped
b) offer the ability to map existing models in more flexible ways

At this point the returning reader might feel a little confused, noticing that the first category is rather close to the topic of the last article. In truth, it actually does overlap, the reason having more to do with the fact that there were too many things to mention in the last article and not enough space to do it in, as well as the fact that these topics kind of span both and form a nice transition from one to the other. But I digress. Let’s move on to the features.

Additional Model Options to Map

Some of the limitations to what you can put in your domain object are due mainly to the time constraints that existed at the time the first version of the specification was being created. Some of the most commonly requested missing mappings were collections of basic types, collections of embedded objects, embedded relationships to other entities, and broader Map support.

Collections of Basic and Embeddable Objects

Collections of things are obviously extremely common, and even though it is possible in JPA 1.0 to have collections of entities, it is not surprising that people might also want to persist collections of non-entities, such as basic objects or even embeddables. To accommodate these two new cases a couple of new annotations were added, currently named @ElementCollection and @CollectionTable. The @ElementCollection annotation is used to indicate that the objects in the collection are stored in a collection table, and the @CollectionTable annotation allows the details of the collection table to be specified. If not explicitly included then default collection table values will apply.

Let’s use the example of a Vehicle that is equipped with a set of possible optional features, where each feature is an enumerated value of type FeatureType. A service visit is an embedded object that stores the date of the visit, the cost, and a description of the work that was done. The basic enumerated FeatureType and embeddable ServiceVisit types look like:

public enum FeatureType { AC, CRUISE, PWR, BLUETOOTH, TV /* … */ }

@Embeddable
public class ServiceVisit {
    @Temporal(DATE) 
    @Column(name=”SVC_DATE”)
    Date serviceDate;

    String workDesc;
    int cost;
}

Now we can use these types in our Vehicle entity, which may have zero or more optional features, and a service history (a list of all of the service visits).

@Entity
public class Vehicle {

    @Id int vin;

    @ElementCollection
    @CollectionTable(name=”VEH_OPTNS”)
    @Column(name=”FEAT”)
    Set<FeatureType> optionalFeatures;

    @ElementCollection
    @CollectionTable(name=”VEH_SVC”)
    @OrderBy(“serviceDate”)
    List<ServiceVisit> serviceHistory;
    …
}

 

The data model would look like:

The @Column annotation on the optionalFeatures mapping refers to the column that stores the feature type value, and as we can see in the data model, it will be in the VEH_OPTNS collection table, not the VEHICLE table.

Published at DZone with permission of its author, Mike Keith.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bernhard Messerer replied on Wed, 2008/06/04 - 7:06am

So this is the JPA of the future? Anybody else diturbed by having five times as many annotations as code - it's becoming sort of an embedded language.

Couldn't find it, but when annotations came up, there was a joke about 'annotation programming', a servlet with 20 or so annotations like '@flow("if user is root then show_admin_link else show_user_link end")' ... (un)funny - whenever we discover something is 'bad' (XML-DDs) we swing completely to the opposite direction and find it equally bad (wait a few years, everybody will scream about the lots and lots of 'heavyweight'annotations unchangeable at runtime) instead of finding the middle ground.

 Messi

Geoffrey De Smet replied on Fri, 2008/06/06 - 1:09am

It feels strange to me that the @Column defines the name of a column on another table. It violates the principle of least surprise (at least to me).

I feel like a seperate annotation or property on @CollectionTable would be a lot more consistent:

@ElementCollection
@CollectionTable(name=”VEH_OPTNS”, columnName="FEAT")
Set<FeatureType> optionalFeatures;

 

Great article. Much better than those (java != dead) articles that litter the frontpage these days. How's the work on standarizing the Hibernate Criteria API going? I am really intersted to see how JPA will define that API.

Donny A. Wijaya replied on Sun, 2008/07/06 - 2:36am

Hi

I wonder if the next JPA 2.0 would include @TypeDef like in Hibernate 3? IMHO, it is a very useful feature. It will allow developers to specify custom type to allow JPA to persist the attribute transparently using the custom type (like in Jasypt and Joda-Time)

Donny

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.