Michael,

Dude, you really have to start a cogent advertising campaign to promote 
Cayenne!  These differences you point out (along with what I understand to be a 
deficiency in faulting behavior over the lifetime of a data object), are not 
insignificant.  (I do believe that they are not widely understood however.)

I was literally asked by a young project lead (in an aggressive tone) "why 
would you ever use anything other than Hibernate".   This leads me to believe 
that they have not done their homework.  I think that they could benefit from 
just the analysis share in today's emails.

I personally think that Cayenne takes the best concepts from NeXT-EOF, and Java 
and have evolved them into a mature Enterprise-ready ORM (something I cannot 
say about the current version of Hibernate).

While it would be great to have a book, and great to have an Entity Diagram 
integrator, I think a simple "Why Use Cayenne" white-paper or web-page that 
succinctly illustrates these differences would accomplish a lot.  Developers 
have come to rely upon and *expect* intelligent garbage collection from Java 
(an arguably non-lanaguage related feature), why not be proactive about 
asserting core Cayenne features as core ORM features in the larger community?

Joe
 



On Sep 6, 2010, at 3:57 PM, Michael Gentry wrote:

> The Hibernate Session is tied to a database connection.  A Cayenne
> DataContext requests a connection from the DB connection pool when you
> commitChanges() or performQuery() and then releases it when done.
> Hibernate therefore has issues in a web application where you don't
> know how many request/response trips will be made from the browser to
> the application -- you can't really leave the database connection open
> indefinitely.  Cayenne's DataContext transparently uses DB connections
> as needed and is more natural in this regard.  Hibernate's proxied
> objects are also tied to their Session.  This creates problems
> (faulting objects, updating and saving, etc) when the Session from one
> request/response was closed and then you try to use the objects in
> another request/response -- you have to re-attach objects to a
> Session.  Cumbersome.  Again, Cayenne does not have these problems.
> This issue was so bad in Hibernate that the Spring community created
> the Open Session In View filter and it still doesn't really solve the
> problems, but it does make it a little better.
> 
> mrg
> 
> 
> On Mon, Sep 6, 2010 at 3:24 PM, Joe Baldwin <[email protected]> wrote:
>> Robert,
>> 
>>> And basically, that's it in a nutshell.  The thread is discussing fetching 
>>> a lazy relationship after the session has closed.  If that were the /only/ 
>>> "fringe case" of lazy relationship navigation in hibernate, it would 
>>> probably be tolerable.  But it turns out, it's /not/ the only fringe case.  
>>> I constantly encounter what I would call "rough edges" around Hibernate's 
>>> lazy fetching.
>> 
>> It took a bit to find a simple quote from the thread, but I think this is it:
>> 
>> "The problem is in Hibernate's lazy loading: you can't load non-initialized 
>> objects after session is disconnected/closed."
>> 
>> I am still a bit confused by the jargon, because I thought "hibernate 
>> session" was analogous to "DataContext".  However, in this thread you 
>> referenced, it sounds like they are using it as if it were analogous to a 
>> "transaction" or maybe even a transient "database connection".
>> 
>> Also, if I understand Gavin, (and as you point out) it sounds as if he does 
>> not embrace "faulting behavior" (aka lazy fetching) as part of the core 
>> responsibilities of an ORM.
>> 
>> If I understand these comments, then I would have to disagree with their 
>> core ORM design pattern, because it is my opinion that intelligent-faulting 
>> behavior is one of the most important functions of an ORM.  NeXT/Apple EOF 
>> (one of the first ORM implementations) included transparent faulting (very 
>> similar to Cayenne in behavior) well before Hibernate was even started.
>> 
>> Again, if I understand the comments, the Hibernate faulting design sounds 
>> like a very primitive and naive implementation.
>> 
>> Am I misunderstanding this (or being too harsh)?
>> 
>> Thanks,
>> Joe
>> 
>> 
>> 
>> 
>> 

Reply via email to