Menu
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?
729
Mapping file : The mapping file (ORM. xml) contains mapping configuration between the data in a POJO class and data in a relational database. JPA Loader : The JPA loader works like cache memory, which can load the relational grid data.
The JPA specification requires the @Entity annotation. It identifies a class as an entity class. You can use the name attribute of the @Entity annotation to define the name of the entity. It has to be unique for the persistence unit, and you use it to reference the entity in your JPQL queries.
An entity can aggregate objects together and effectively persist data and related objects using the transactional, security, and concurrency services of a JPA persistence provider.
Basic entity mapping You just add an @Entity annotation to the class and an @Id annotation to the primary key attribute. Hibernate maps the entity to a database table with the same name and uses a default mapping for each attribute. You can define the same configuration with the following XML file.
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:
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.
22
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.
84
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
