Mike, others:
What I was referring to in my message is "Hibernate session was
closed" problem - something that I've seen a number of people complaining
about (see a summary posted by Eric -
http://www.objectstyle.org/cayenne/lists/cayenne-user/2004/09/0121.html).
I don't have much POJO ORM experience myself. I used TopLink on one
project and it was quiet a pain - it was required to manually clone the
right parts of the object graph when going from read-only shared graph to
read-write "UnitOfWork" (when you are passed an object reference somewhere
in a method, you have no idea whether this is a mutable clone or a
read-only "master")... Probably a big part of the problem was related to
how we (mis)used it, but the points I learned were:
1. separation objects into "contexts" is important.
2. A bi-directional link between object and its context makes life much
easier.
With POJO Cayenne bidirectional link becomes uni-directional (from context
to objects). So things like syncing, etc. we can handle without
POJOAdapter (which I thought would be just a temp transitional thing)...
However back-reference to context will be provided via some hack like
thread-bound DataContext, so expect "Cayenne session was
closed" exceptions for cases like firing faults or relationships... Though
as we don't wrap DataContext in transaction, it will still be better than
others... Also there will be "attach" step to bind your object graph to a
DataContext - this will require users to be very careful in what they
do... Right now its all taken care of by Cayenne.
Andrus
> =================================
> I'm looking for some comments about the "problems of Hibernate". All
> the
> massive marketing that arounds it doesn't allow us to know its weakness.
> Could you (and anybody else) list and compare these problems?
> =================================
>
> I have only used ORM layers (WebObjects/Toplink/Cayenne) that were
> subclasses of a "DataObject" kind of class, so I'm no expert on POJO
> ORM.
>
> However, one thing I see right off with just POJO is that you no longer
> have any reference from your POJO to its model. My applications tend
> to use validation based on our database models.
>
> Second, if your data is only represented as a POJO, then it's only
> associated with the database when you perform an operation
> (commit/select).
> That means that a change to the database can not resync your POJO
> object
> back to match the database state as there's no connection between the
> two.
>
> Consider the simple case of a web app with two sessions modifying the
> same database object.
> In Cayenne, as soon as one session commits a change to the object, the
> other DataContext will update the backing store of the object as well
> to match those changes.
>
> Things get much more complex when you start wanting to use remote
> notification changes between applications.
>
> You could minimize these problems to some extent by registering them in
> a list and mapping each list entry to a database model. I'm not sure
> if that would cover all situations, but it might.
>
>
> I guess in the end, the only "cost" of supporting POJO objects would be
> to keep a separate matched DataObject for each one (That's probably
> what Andrus is calling a POJOAdaptor), then search through that list
> (probably a HashMap) to match a POJO with its Cayenne DO.
>
> -Mike
This archive was generated by hypermail 2.0.0 : Wed Jan 19 2005 - 14:02:40 EST