Issue #21: ObjectDB 2 JDO Manual

The new ObjectDB Manual describes how to use ObjectDB 2 with JPA.

An additional manual that focuses on using ObjectDB 2 with JDO can help JDO users.

But since writing a new manual and then maintaining two similar manuals, one for JPA and the other for JDO requires massive work, this will be done only if there is a sufficient demand.

As a user of the JDO side of ObjectDB a JDO focused manual would be helpful.  Or at least a pointer to a known good set of standard JDO references.  I've found that most questions arise regarding the enhancement of classes and the definition of the XML file describing those classes that are to be enhanced, that and the use of JDOQL when creating queries.

I second making a specific JDO manual

Me too.

I use ObjectDB as an esy-to-install and free example of an object database in a university course on database technology. Last year we used odb104fe, and I was happy to see the updated web page and the support for JPA when I returned to your site today. However, it is difficult to see how sincere you support of JDO 2 is when you don't even have a small demo example.

I understand that keeping two manuals up to date is a lot of work, but I would suggest that you a least make the Quick Start also for JDO. However, as I am not buying a license ....

By following an old link I found out that the old JDO 1 manual is still accessible from the Knowledge Base, and some advice for upgrading to JDO 2 too. Maybe that would be worth mentioning under JDO in the dropdown menu.

Thanks for ObjectDB, Fredrik

JDO is the difference between ObjectDB probably being a great solution for me, and my looking usewhere for a solution. But, for the last few days I have been having significant trouble finding the information I need to use JDO in general, and ObjectDB's implementation in particular.

I think there must be many potential customers similar to me who have used Object databases for many years who are being lost due to a lack of JDO documentation.

1) makes working with a product so much harder

2) suggests a strong possibility that you are considering removing JDO support from the product.

If we can believe what we are told, db4o has hundreds of thousands of current users. Most of those users are probably now looking for a new product, due to what seems to be its abandonment by its new owner. I suggest an investment in a JDO manual would likely be a good one. JPA would not be of interest to most people currently using Object databases.

We do see ex db4o users moving to ObjectDB recently, but db4o does not support JDO, so there is no particular advantage in moving from db4o API to JDO rather than to JPA.

JPA is much more popular than JDO these days, and accordingly most ObjectDB users use JPA.

Not many active products still support JDO. ObjectDB is one of the last. It seems also that nearly every active product that supports JDO, now also supports JPA. The most popular persistence frameworks (Hibernate, EclipseLink) support JPA but do not support JDO.

You wrote that "JPA would not be of interest to most people currently using Object databases.". I am afraid we do not agree on this. Why do you think so? What are the advantages of preferring JDO over JPA in your specific case?

First, my apologies for the double post; I didn't see my first and thought for some reason it didn't get posted.

(Didn't expect such a fast response either.)

I don't see anything about JPA that would make it inadequate to do what I want, I just see it as an ORM tool used to awkwardly map an object language to an object database. And I agree with most of the comparisons that we've probably all seen on the Web concluding that JDO is a superior API for object databases.

I am not however, married to JDO, although I think it's good. Its lack of true (before commit) pessimistic locking is something I miss, for example, and it to some degree it is a compromise needed to reach an agreement among stakeholders. I'm actually thinking that the people who did such a good job at designing ObjectDB would be able to build an equally superior native API.

Notwithstanding the issues, ObjectDB (especially) and JDO seem capable of doing an excellent job for the business applications I plan on using it for while you're still supporting it.

Is there some link you can provide me with (other than on your site, which I've gone over fairly thoroughly) for more documentation?

> I agree with most of the comparisons that we've probably all seen on the Web concluding that JDO is a superior API for object databases.

Please look carefully who published these comparisons. Actually the differences between JPA and JDO technical capabilities are quite small for most users, and in some of them JPA is better (e.g. in locking, as you noted).

I think you need really good reasons to base a new application on JDO rather than on JPA.

> Is there some link you can provide me with (other than on your site, which I've gone over fairly thoroughly) for more documentation?

This is one of the problems with JDO today: No new books and merely no up to date resources.

You can either use DataNucleus documentation or the JDO specification pdf.

If up to date documentation is essential, you should consider using JPA.

A JDO manual is no longer useful to me; I am switching to JPA.

A vendor's advice on how best to use his product is almost always good advice. Since I have no compelling reason to use JDO, I'm going to take that probably good advice (above).

I've also since starting with JDO, a couple of weeks ago, read most of the ObjectDB JPA manual and have found that ObjectDB does not enforce many of the aspects of JPA that I found unattractive.

This switch to JPA makes me more comfortable in investing valuable time and effort in the ObjectDB product and company as a possible best and excellent solution to my persistence needs for at least the next five years.