Try it. And catch it, finally.

Provided you are already working with some JPA/Hibernate mapped Database, it would be very useful to have a generic and out-of-the-box working Database Import/Export mechanism at hand, which in the most generic case solely works on the JPA configuration/mapping already in place, for more sophisticated cases with some additional configuration. Such a mechanism should in my mind probably allow

• To export the whole Database in a Vendor Unspecific, Java centric way and serialize it to some appropriate (probably XML-based) Data Format
• To recover the whole Database to exactly the State represented in the Export.
• To limit the Export to some Tables/Entities to be exported.
• To make use of different Import Strategies when it comes to importing Entities into a non-empty Database. I think here of applying different Deletion Strategies – probably configurable per Entity Class – whenever importing instances of any given Class found in the Dump, cause I already stumbled upon practically applicable Use Cases for all of them:
  1. Deleting all (mapped) Entities in the Database.
  2. Deleting all Entities of the Hierarchy of the Class found in the Dump.
  3. Deleting all Entities of the Class found in the Dump.
  4. Deleting just the Entity found in the Dump itself.
  5. Not deleting anything, but just populating an eventually preexisting Entity found in the Database with the Properties found in the dumped Entity.
• To alternatively base the “Identity” of a Dumped Entity not on it’s Database Primary Key, but on some configurable “natural” Key Values which can be found among its Properties.
• To be aware of whether the Database Schema matches the Dump, and potentially also whether the Version of the Software working with the Data represented in the Database matches the Dump, and throw appropriate warnings and/or errors if not. (Maybe the desirable behaviour will depend on the requested Import Strategies for the Entities in the Dump.)
• To be able to import Dumps produced with older versions of the Import/Export Tool itself.

A bit more investigation needed. It could turn out, that the basic features can be relatively easily achieved based on Hibernates XML serialisation format. Surely, we remember: nothing is as easy as espected. (On the other hand: exactly because of this truth we should also be wise enough not to expect everything to be difficult. Provided the statement “nothing is as easy as espected” is true, our expectations will influence how hard our time with an issue will turn out to be in the end. Won’t they?

(This post is part of my thoughts about A portfolio for Enterprise Web Applications)

In my last project I ran into an “actually” quite obvious trouble I want to resolve properly once and for all times, because I expect it to be a regular requirement when working with something like JPA/Hibernate persistence layer and something like the Spring Framework Bean Instantiation mechanism.

When I persist some JPA mapped Entity into my database, I’d later on very much like to be able to recover it exactly in the state when it was persisted. This is what persistence is all about anyway, isn’t it? It is, but troubles arise when this persisted Entity originally was instantiated based on some Spring Prototype Bean Configuration. Typically, Parts of the Properties of such a prepopulated Beans are just for Configuration Purposes and to persist those Properties to the Database is either obsolete and causing a lot of redundant and performance burdening data (in case of e.g. simple configuration values or beans), but can also turn out to be difficult or impossible to achieve in case the injected Data (e.g. some Configuration carrying Singleton Bean) is just not made to be persistent.

However, later on, when recovering such an Entity from the Database it will have lost all it (non-persistent) configuration data. Of course: JPA/Hibernate constructs the Java Objects via the Default Constructor of the Class and populates it with the Property Values persisted in the Database. That’s it, basically. The solution for my issue should be easy and some instructions and/or even ready code should be obtainable via the Internet: I just have to “teach” Hibernate to construct the Java Objects derived as Database Entities not via the default Class Constructur but via the Spring Bean Instantiation. I “just” have to do some research about this…

Once having this in place, I expect such an approach to turn out to make very good sense for almost all persistent Entities, also for the simple cases, because it allows

• To externalize the configuration of transient-only Property values with default (prepopulated) values becoming persistent later on and to have all this transparent in one place within the Spring Prototype Bean Configuration.
• Domain specific Object Models to carry some (e.g. DAO aware) lookup or logic methods in case applicable and useful.

I’m eager to see it working soon!

(This post is part of my thoughts about A portfolio for Enterprise Web Applications)