Skip to main content

Persistence of JScience components a no-go?

Posted by saintx on February 10, 2008 at 10:05 AM PST

When I first stumbled upon the JSR-275 standard units RI at JScience.org last autumn, I was very impressed with its careful design and eager to use it in my projects. That was before I began working on JPA persistence annotations for my data model. Now I regret using this otherwise wonderful package, for I've become entrenched in an ugly decision between shedding JScience.org dependencies entirely and reimplementing, annotating a partial branch of JScience.org for use in my project, or building some kind of bridging data class and corresponding transformer layer.

Neither option is attractive. Lesson learned.

Related Topics >>

Comments

We recently used an implementation of the successor to ...

We recently used an implementation of the successor to JSR-275, Unit-API with JPA2 and it worked extremely well.

This particular implementation at BT benefited from an enum-based implementation, but it's not the only way this should work rather well.

Some of the new JPA 2 features made it easier, so maybe your Lessons learned 3 years ago suffered from multiple reasons?
I was involved in JScience-JPA, but the majority of the project at the time was still based on "good old" plain Hibernate mappings.

We used the Hibernate implementation, but pure standard-complient JPA 2 in this new case.

I used the predecessor of JSciense.org and had to build bridging classes in order to serialize/deserialize to a database.

You would have thought that that problem would have been resolved in the jsr. but no, just read the forum on javalobby were the question was asked to the owners of jsr275. (http://www.javalobby.org/java/forums/t98361.html)

I hope the jsr will not be included in java 7 if these problems are not solved.

Incidentally there is a JScience-JPA project which presumably is trying to address the problems. https://jscience-jpa.dev.java.net/

What is that goes wrong?

Err, make that:

I end up with collection-valued reference fields for things like:

Set<Amount<ProductType>> s = new HashSet<Amount<ProductType>>().

Etc.

One of the things I'm trying to do is work with Amount, Unit and Quantity types in the sense that a product instance becomes a unit that can be measured and represented by an Amount. In my application, this works like a charm and is an absolute pleasure to use. However, things get rocky the moment I need to persist these objects.

I end up with collection-valued reference fields for things like:

Set> s = new HashSet>().

Because Amount is not an Entity, I can't do this. Because it's Final, I can't extend it with an object that can be an entity. This is not good for me, and it really impacts performance.

When I try to persist these types of collections, I get problems like this from OpenJPA:

"OpenJPA cannot map field "org.eremite.corm.product.PackageType.components" efficiently. It is of an unsupported type. The field value will be serialized to a BLOB by default"

The only option that I can see is to create an object that represents an Amount to my data model, which will give me an org.jscience.physics.amount.Amount when asked for (via some kind of a getScientificAmount(...) method) I'm not clear how else I could do this.

One possible origin of this problem is the mixing of data-holding and data-manipulation roles in the same object (such as Amount). In a system better engineered for persistence, you'd have objects which were themselves nothing more than passive data beans, and other objects that performed manipulations on those--preferably stateless transformation components. Such a system could be easily made persistent.

I see this problem duplicated in the Unit class and its derivations. All of these objects mix the data and data manipulation roles in a way which muddies them for purposes of persistence. My proposed solution (and the one I'm investigating right now in my project) is to isolate the data representation features into their own objects, and use factories to create the data manipulation features as needed by my application logic.

I will definitely check out the JScience-JPA project and the dev list. Thank you all for your helpful comments!

Hi Alexander, Could you let us know what are the problems you encountered and what solution did you try? It would be the right time now to try fixing this problem. Please send us your comments/proposal at dev at jscience dot dev dot java dot net Thanks, Jean-Marie (JScience project owner).