Re: JDO comparisons

Eric Samson wrote:
> JDO QL can surely be improved, you're right.

My 2 cents:
JDO QL is not worth improving.
It can simply be thrown away.

> But the initial question was about going on with JDBC or switching to JDO.
> How do you simply QUERY MAPS with JDBC ?
> How do you deal with simple collections or inheritance ?

The problem is:

The installed base of applications relies heavily on complex SQL queries. JDO QL is by no means a replacement.

There are some rare complex object-oriented applications that need deep inheritance hierarchies. These applications have been flirting with object databases in the past. New projects might consider to go for JDO since there is small hope, that quite a few vendors will support the standard. The drawback against JDO implementations that map to relational databases:
They are slow and they will always be slow.

I see three prototypes of customers:
(1.) Business applications with normal flat hierarchies: They will continue to use SQL since they need the query capabilities.
(2.) Applications with deep inheritance hierarchies and high demands for performance:
They will get the best results with the tightest object database integration they can get. Additional overhead by routing through a JDO layer [1] will not be benefitial.
(3.) Developers looking for the easiest way to store objects. They will not like JDO since it is much more complex than necessary.

Where are the JDO customers?
Of course there will always be mainstream idiots that value company names higher than technology. Too bad for them. Go with Enron.

We target the customer types (2) and (3) and we feel that we will get along perfectly without supplying a JDO implementation. Should JDO be around in a year or two and should the JDO query interface be replaced by something decent, we still have the decision open to invest the manyear to provide a JDO implementation on top of our API.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com


[1] I expect all quickly available JDO implemenations
to be add-ons to existing database engines. The JDO
part will be an intermediate library like you seem
to be providing one.