In the previous blog in the JPA implementation patterns series, I talked about the three default ways of mapping inheritance hierarchies using JPA. And introduced one non-standard but quite useful method. This week I will discuss various approaches to testing JPA code.

What to test?

The first question to ask is: what code do we want to test? Two kinds of objects are involved when we talk about JPA: domain objects and data access objects (DAO's). In theory your domain objects are not tied to JPA (they're POJO's, right?), so you can test their functionality without a JPA provider. Nothing interesting to discuss about that here. But in practice your domain objects will at least be annotated with JPA annotations and might also include some code to manage bidirectional associations (lazily), primary keys, or serialized objects. Now things are becoming more interesting...
(more...)

Filed under JPA, JPA implementation patterns, Java, Spring, Testing, fitnesse | 3 Comments »

Last week I discussed the relative merits of field access versus property access in the ongoing JPA implementation patterns blog series. This week I will dwell on the choices offered when mapping inheritance hierarchies in JPA.

JPA provides three ways to map Java inheritance hierarchies to database tables:

1. InheritanceType.SINGLE_TABLE - The whole inheritance hierarchy is mapped to one table. An object is stored in exactly one row in that table and the discriminator value stored in the discriminator column specifies the type of the object. Any fields not used in a superclass or a different branch of the hierarchy are set to NULL. This is the default inheritance mapping strategy used by JPA.
2. InheritanceType.TABLE_PER_CLASS - Every concrete entity class in the hierarchy is mapped to a separate table. An object is stored in exactly one row in the specific table for its type. That specific table contains column for all the fields of the concrete class, including any inherited fields. This means that siblings in an inheritance hierarchy will each have their own copy of the fields they inherit from their superclass. A UNION of the separate tables is performed when querying on the superclass.
3. InheritanceType.JOINED - Every class in the hierarchy is represented as a separate table, causing no field duplication to occur. An object is stored spread out over multiple tables; one row in each of the tables that make up its class inheritance hierarchy. The is-a relation between a subclass and its superclass is represented as a foreign key relation from the "subtable" to the "supertable" and the mapped tables are JOINed to load all the fields of an entity.

A nice comparison of the JPA inheritance mapping options with pictures, and including a description of the @MappedSuperclass option, can be found in the DataNucleus documentation.

Now the interesting question is: which method works best in what circumstances?
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java | 5 Comments »

Last week my colleague Albert Sikkema blogged about using UUIDs as primary keys. Interesting stuff, thanks again, Albert! This week I will continue the JPA implementation patterns series by discussing the relative merits of field access vs. property access.

The JPA specification allows two ways for the persistence provider to access the persistent state of an entity. The persistence provider can either invoke JavaBeans style property accessors (getters and setters) or access the instance fields of the entity directly. Which method is used depends on whether you have annotated the properties or the fields of an entity.
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java, Performance | 1 Comment »

Two weeks ago I blogged about the use of the Service Facade and Data Transfer Object pattern in JPA application architecture. This week I will move from the high level perspective and discuss an interesting interaction I discovered between the way bidirectional associations are managed and lazy loading. So let's roll up our sleeves and get dirty in this next installation of the JPA implementation patterns series.

This blog assumes that you are familiar with the Order/OrderLine example I introduced in the first two blogs of this series. If you are not, please review the example.

Consider the following code:

OrderLine orderLineToRemove = orderLineDao.findById(30);
orderLineToRemove.setOrder(null);

The intention of this code is to unassociate the OrderLine with the Order it was previously associated with. You might imagine doing this prior to removing the OrderLine object (although you can also use the @PreRemove annotation to have this done automatically) or when you want to attach the OrderLine to a different Order entity.

If you run this code you will find that the following entities will be loaded:

1. The OrderLine with id 30.
2. The Order associated with the OrderLine. This happens because the OrderLine.setOrder method invokes the Order.internalRemoveOrderLine method to remove the OrderLine from its parent Order object.
3. All the other OrderLines that are associated with that Order! The Order.orderLines set is loaded when the OrderLine object with id 30 is removed from it.

(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java | 7 Comments »

In my previous blog on JPA implementation patterns, I touched upon the subject of the DTO and Service Facade patterns. In this blog I will explore why we would even need such patterns and put these patterns and the DAO pattern into the broader context of JPA application architecture.

If there is one thing that I learned when implementing JPA for the first time is that some of the "old school" enterprise application architecture patterns still apply, even though some people have proclaimed them to be no longer necessary:

• The DAO has been declared dead because you might just as well invoke the EntityManager directly. It provides a nice enough interface and switching from JPA to a different persistence implementation is not something the DAO abstraction would make much easier.
• DTO's have been deemed superfluous because you can also use your domain objects directly in the presentation layer. This is made possible by a combination of the open EntityManager in view pattern, tag libraries to display your domain objects in JSP's and data-binding utilities to map HTTP request parameters back to domain objects.
• And finally Service Facades also seem to have gone out of fashion. Instead you can have the controller directly invoke the services it needs or, even simpler, directly contain the business logic.

(more...)

Filed under JPA, JPA implementation patterns, Java, Spring | 18 Comments »

In the previous three blogs about JPA implementation patterns, I covered the basis operations of saving entities, retrieving entities, and removing entities. In this blog I will continue along a different angle, exploring the subject of how entities are lazily loaded and how that affects your application.

Anybody that has been working with Hibernate for a while has probably seen a LazyInitializationException or two, usually followed by a message such as "failed to lazily initialize a collection of role: com.xebia.jpaip.order.Order.orderLines, no session or session was closed" or "could not initialize proxy - no Session". Even though these message may baffle new users of Hibernate, they are a lot better than the NullPointerExceptions OpenJPA gives you in these cases (at least when using runtime bytecode enhancement).

To use JPA to its full potential it is imperative to understand how lazy loading works, as it allows you to model your complete database with all its relations without loading that whole database as soon as you access just one entity.
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java, Spring | 15 Comments »

For the last few weeks I have been covering the implementation patterns I discovered while writing JPA applications. The last two blogs covered saving entities and retrieving entities. But when you're really through with your entities, I guess you'd want to remove them too. So that is the subject of this blog.

Just like retrieving an entity, removing an entity is pretty simple. In fact it's all you need to do is pass the entity to the EntityManager.remove method to remove the entity from the database when the transaction is committed (Of course you'd actually invoke a remove method on your DAO which in turn invokes EntityManager.remote). That's all there is to it. Usually. Because when you're using associations (be they bidirectional or not) things get more interesting.
(more...)

Filed under Hibernate, JPA, JPA implementation patterns, Java | 14 Comments »

Last week I talked about how to save an entity. And once we've saved an entity we'd also like to retrieve it. Compared to managing bidirectional associations or saving entities, retrieving entities is actually rather simple. So simple I doubted whether there would be much point in writing this blog . However we did use a few nice patterns when writing code for this. And I'm interested to hear what patterns you use to retrieve entities. So here is the next instalment in the series on JPA implementation patterns.

Basically, there are two ways to retrieve an entity with JPA:

• EntityManager.find will find an entity by its id or return null when that entity does not exists.
• If you pass a query string specified in Java Persistence Query Language to EntityManager.createQuery it will return a Query object that can then be executed to return a list of entities or a single entity.

(more...)

Filed under JPA, JPA implementation patterns, Java | 16 Comments »

We kicked off our hunt for JPA implementation patterns with the Data Access Object pattern and continued with the discussion of how to manage bidirectional associations. This week we touch upon a subject that may seem trivial at first: how to save an entity.

Saving an entity in JPA is simple, right? We just pass the object we want to persist to EntityManager.persist. It all seems to work quite well until we run into the dreaded "detached entity passed to persist" message. Or a similar message when we use a different JPA provider than the Hibernate EntityManager.
(more...)

Filed under JPA, JPA implementation patterns, Java | 12 Comments »

Last week we started our search for JPA implementation patterns with the Data Access Object pattern. This week we continue with another hairy subject.

JPA offers the @OneToMany, @ManyToOne, @OneToOne, and @ManyToMany annotations to map associations between objects. While EJB 2.x offered container managed relationships to manage these associations, and especially to keep bidirectional associations in sync, JPA leaves more up to the developer.
(more...)

Filed under JPA, JPA implementation patterns, Java, Performance | 28 Comments »