JPA: Should I clear entity classes using orm.xml?

Question

Currently I use only JPA annotations, but I really don't like the fact that I pollute entity classes with so many ORM details that really are not related to their behavior (for example, table name, identifier generation strategies, join columns ...) .

I see that DataNucleus recommends putting ORM-related annotations in XML instead (colored in pink), but I have not seen any other implementation recommends this, and JPA does not seem to split the annotations into these two groups (I think JDO does).

Does anyone use annotations + orm.xml in this way and what are your experiences?

Will any pollution be removed from my entity classes, or will I run into problems?

Answer 1

The biggest problem that we have encountered on a regular basis is that if you want to change the display of persistence in any , using only annotations, you need to recompile and redeploy.

Using orm.xml gives you a degree of abstraction, which can make reconfiguration a bit more straightforward and technically achievable with the same code base (for example, you are sure that the line of code has not penetrated the re-compilation / redistribution).

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

We are still trying to develop some clear heuristics when we use one configuration mechanism over another, but we get there.

Answer 2

JPA entities are simply Java Beans (classes that define getters and setters) with additional supporting code (constructors, hashCode, equals, named queries, copy methods, what else?) Can hardly be considered dirty even with all types of JPA annotations included.

The real goal of sharing metadata between Java and xml annotations would be to simplify and optimize deployment policies. The price you incur is double:

• ensuring metadata policy development belongs to that place and
• cross-referencing java and xml when creating and especially supporting metadata (more or less, but always inconvenience).

Both are pretty serious considerations when working in a medium and large development team.

If recompiling for database changes is a serious problem in the deployment process, then this sounds like a reasonable approach. But the price will be a more complex development environment, process and service policies.