Re: JDO comparisons
Date: Mon, 18 Feb 2002 14:22:12 +0100
Message-ID: <a4qv6e$b5l$01$1_at_news.t-online.com>
Eric, thanks for the friendly words, in spite of my usual rant-tone, when it comes to JDO.
Some comments:
> 1. JDO for SQL too slow. This mainly depends on the implementation. On
> standard objects manipulation we show better performance than JDBC,
> for instance just because we have a client cache (as an ODBMS).
Yes, a cache may solve the speed problem, but it may introduce locking and updating problems.
> About queries, we know this objection, and address it giving our
> LiDO-JDBC users a way to map SQL queries and compiled queries when
> they need manual tuning.
It would be very nice if we could keep a bypass-SQL mechanism away from our objects, since it does not know about the cache and possible locks in the object system.
> 2. Our JDO Versant implementation is even faster than the Versant Java
> interface.
Congratulations!
I suppose that this is not a compliment for Versant's Java implementation.
> The JDO client wrapping layer around an ODBMS is not something
> important, regarding other global performance factors like
> network usage and so on.
I wouldn't be to sure on this one. Locking is the big issue.
> (BTW one prospect requested us for db4o support ;-)
Great! If you get more of the kind, we don't even have to code a JDO implementation ourselves. :-)
> 3. a JDO application is as easy to code as if you had an ODBMS (it's a
> virtual OBDM on top of any physical data store).
This strongly depends on the API of the underlying object database. Most of it is fairly straight-forward but the query and the locking part is tough.
> I know the very long
> "discussion" you had with JDO experts a while ago, IMHO it mostly
> comes from your reluctance of what JDOQL is (probably yet another
> endless holly war in the "Object Query" arena).
The discussion is continuing. :-)
There is nothing holy about it. We definitely need a standard but it needs to be a good one. The whole point about using object databases (or O-R mappers) is the good integration with OO languages:
(1) use objects (2) store objects (3) retrieve objects (4) use objects for queries
Why do most of the common object persistence APIs including JDO fail to stay object-oriented and introduce a String-based querying API? I just don't understand it. There is nothing wrong abot supplying a String querying mechanism (OQL) for human ad-hoc queries *on top* of an object-querying API but life could be so much simpler if we could agree on a common underlying object oriented API.
It would make the development of common reporting tools so much easier and we might even be able to run a client from one object database vendor with another object database vendors server.
> I can see the JDO community growing very fast these days.
I know POET is pushing it. I see the JDO integration into Forte. I have also read quite a bit about new products like Libelis LiDO.
I can't help my technical opinion against the API. I am strongly in doubt that we will see many *complete* JDO implementations that will work smoothly in multi-user environments.
> I wish you all the best with db4o which is a nice,
> well-targeted product.
Thanks a lot for the compliments. All the best wishes for Libelis and LiDO back to you!
> I'm quite sure you'll join the JDO wave sooner or later.
We will see. Not this year for sure.
Kind regards,
Carl
--- Carl Rosenberger db4o - database for objects - http://www.db4o.comReceived on Mon Feb 18 2002 - 14:22:12 CET