JPA: Should I clean up my entity classes using orm.xml?

Question

I currently use JPA annotations only, but I really don't like that I'm polluting my entity classes with so many ORM details which really aren't relevant to their behavior (e.g. table name, id generation strategies, join columns...).

I see that DataNucleus recommends putting ORM-related annotations in XML instead (those colored in pink), but I haven't seen any other implementations recommend this and JPA doesn't seem to separate annotations into these two groups (I think JDO does).

Is anyone using annotations+orm.xml in this way, and what are your experiences?

Will it remove some of the pollution from my entity classes, or will I run into problems?

Answer 1

The biggest issue we've faced on a semi-regular basis is that if you want to change your persistence mapping in any way using annotations alone you need to recompile and redeploy.

Using orm.xml affords you a degree of abstraction which can make reconfiguration a little more straight forward, and achievable with technically the same code base (eg you're sure that a line of code hasn't snuck into what you're recompiling/redeploying).

You can use both annotations and configuration - which is the environment I'm now working with - classes are annotated with functional type persistence metadata (i.e. foreign keys, joins, etc - things which have a code level representation) while irrelevant information (i.e. table/column names) are stored in configuration files.

We're still trying to develop some clear heuristics around when we use one configuration mechanism over another, but we're getting there.

Answer 2

JPA entities being just Java Beans (classes defining getters and setters) with optional supporting code (constructors, hashCode, equals, named queries, copy methods, what else?) could hardly be considered polluted even with all types of JPA annotations included.

The real purpose of splitting metadata between Java annotations and xml would be simplification and optimization of deployment policies. The price that you will incur is two-fold:

1. enforcement of development policies regarding what metadata belongs to which place and
2. cross referencing java and xml when creating and especially maintaining metadata (more or less but always inconvenience).

Both are rather serious considerations when working in average to large size development team.

If recompiling for database changes presents a significant challenge in your deployment process then it sounds as a reasonable approach. But the price will be more complex development environment and process and maintenance policies.

Answer 3

Hardly considered polluted? Hardly thought through answer.

Consider domain classes that are used in more than your own silly little application and are used company wide. The applications that have nothing to do at all with JPA will be forced at gunpoint to deal with JPA. So what happen to "pay for only what you use?"

Sorry, I've eaten enough Elephant in my time with EJB from .85 through 2.1 and I'm not eating any more.

So if you are writing an application for just you and/or you are relying on Tools rather than learning keep the tool's autogenerated annotations. If you are writing company wide domain classes put the JPA stuff in orm.xml.