How do I use JPA to make library objects database persistent?

Question

I've been using JPA on a small application I've been working on. I now have a need to create a data structure that basically extends or encapsulates a graph data structure object. The graph will need to be persisted to the database.

For persistable objects I write myself, it is very easy to extend them and have the extending classes also persist easily. However, I now find myself wanting to use a library of graph related objects (Nodes, edges, simple graphs, directed graphs, etc) in the JGrahpT library. However, the base classes are not defined as persistable JPA objects, so I'm not sure how to get those classes to save into the database.

I have a couple ideas and I'd like some feedback.

Option 1)

Use the decorator design pattern as I go along to add persistence to an extended version of the base class.

Challenges:

-- How do I persist the private fields of a class that are needed for it to be in the correct state? Do I just extend the class add an ID field, and mark it as persistable? How will JPA get the necessary fields from the parent class? (Something like ruby's runtime class modification would be awesome here)

-- There is a class hierarchy (Abstract Graph, Directed Graph, Directed Weighted Graph, etc.). If I extend to get persistence, extending classes still won't have the common parent class. How do I resolve this? (Again, Something like ruby's runtime class modification would be awesome here)

Option 2) Copy paste the entire code base. Modify the source code of each file to make it JPA compatible.

-- obviously this is a lot of work

I'm sure there are other options.. What have you got for me SO???

Answer 1

Your options with JPA annotations seem pretty limited if you're working with a pre-existing library. One alternative would be to use something like Hibernate XML mapping files instead of JPA. You can declare your mappings outside of the classes themselves. Private fields aren't an issue, Hibernate will ignore access modifiers via reflection. However, even this may end up being more trouble than its worth depending on the internal logic of the code (Hibernate's use of special collections and proxies for instance, will get you in hot water if the classes directly access some of their properties instead of using getter methods internally).

On the other hand, I don't see why you'd consider option 2 'a lot of work'. Creating a ORM mapping isn't really a no brainer task no matter how you go about it, and personally I'd consider option 2 probably the least effort approach. You'd probably want to maintain it as a patch file so you could keep up with updates to the library, rather than just forking.

Answer 2

Do the base classes follow the JavaBeans naming conventions? If so you should be able to map them using the XML syntax of JPA.

This is documented in Chapter 10 of the specification:

The XML descriptor is intended to serve as both an alternative to and an overriding mechanism for Java language metadata annotations.

This XML file is usually called orm.xml. The schema is available online