Monday, October 6, 2008

DataNucleus

On a former post, I've had some comments (it's rare :-) ), and especially some from Andy who talked about DataNucleus above DB4O, but also more generally above quite every persistent layer while providing a standardized JPA API for accessing data. I've not yet tried this technology, and I've then no advice about it.
Here can you find what Andy said about DataNucleus :"
What are the benefits of a standardised API ?
So you can in principle swap your persistence process to an alternative implementation. Developers don't need to learn a proprietary API.

What are the benefits of using DataNucleus in this respect?
You can use db4o for persistence, but then also persist data to LDAP, or RDBMS, or XML, or Excel, or ... with a simple change of a URL (no changes to your data model, or persistence code). Also since DataNucleus jars are already OSGi enabled you can just drop them in your container rather than having to add special treatment.

1) more developers who already know standardised APIs (JDO/JPA) and 2) you have other benefits by choosing that route. Please define where the disadvantage is ?

Assuming your developer doesn't know any persistence API, what is the learning curve for the db4o API? about the same as JDO/JPA IMHO, however they'll find more docs for JDO/JPA since there are more implementations. You don't code to DataNucleus proprietary APIs.

Speed ? very little difference to db4o native speed. No need to use db4o transparent persistence/activation since its done for you by DataNucleus. You can have application identity capabilities (define primary key fields in your class) using JDO/JPA and DataNucleus whereas with db4o's API this is impossible.

The DataNucleus site has adequate documentation of the available APIs should you be interested."

I would like to hear experience return from users... Don't hesitate to write comments :-)

No comments: