Re: [Hibernate-devel] Comparison with Castor?

[Gavin_King/Cirrus%<CI...@ci...>]

Hi Cuong :)

I feel somewhat uncomfortable answering this question since I havn't used
Castor myself. I _have_ spent a little bit of time the last couple of days
trying to make sense of their documentation (which is very bad) and
examples (which are virtually non-existent). So I'm not going to be able to
give a really definitive answer to this.

It _is_ clear that Hibernate + Castor have similar approaches in that they
share the following:

XML O/R mapping,
use of reflection,
diffing objects to determine which objects need updating,
support for optimistic locking,
OO query language

and even some of the API looks pretty similar.

On the other hand, it seems that the two projects differ in their emphasis
in at least these aspects:

architecture,
documentation,
supporting tools,

Architecture first: Hibernate is an as-thin-as-possible object/relational
persistence service. Many OR persistence layers end up implementing an
OODBMS that uses a relational database as a file system. I think Castor has
gone down this path of essentially having two databases; an OODB in RAM and
an RDB on the disk. This approach has the single advantage that it permits
cacheing in the persistence layer. It has the disadvantage of being
arguably less scalable and much less robust. Have a quick look at Castor's
changelog and check how many of their bugs are to do with concurrency
issues. Hibernate is essentially immune to concurrency bugs because its
critical code is single threaded! We let a mature relational database
handle concurrency because thats what they do well.

My understanding (this was stated explicitly in the Castor mailing list but
I can't find anything addressing the issue on their website) is that Castor
cannot operate in a cluster (or, presumably, when sharing access to the
database with other applications or JVMs).

Hibernate comes with about 25 pages of (growing) documentation of how to
actually use it, with (hopefully) clear explanation of the semantics of
various things. We also have an automatic table schema generation tool and
will soon have a map generation tool. Castor can't create tables for you,
you need to write SQL scripts by hand. To me, hibernate is more than about
providing a persistence mechanism, its about speeding up the development
process. This is, I think, a very essential difference. The project was
motivated by my frustration with low-productivity in J2EE environments, not
by my difficulty persisting objects :)

I wish someone who knows Castor would draw up a feature matrix comparing
the two projects. At the moment the only thing I noticed they are missing
is support for what we call "components" and the only things we are missing
are support for auto-increment columns + oracle sequences for key
generation. But I'm sure there are heaps of other things.

Components are actually a _really_ cool feature since they let you store a
whole graph of objects in a single row of a table. This lets you use a much
finer grained object model and still get acceptable database performance
(no need for a table join for each dependent object).

Actually another difference is they allow _associated_ objects to be
"lifecycle" objects, whereas we only allow components and collections as
lifecycle object. We will add this feature at some stage.

Hopefully in future I will be able to answer this question more accurately.

Gavin