cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Baldwin <jfbald...@earthlink.net>
Subject Re: lazy loading (slightly OT but still pretty important)
Date Thu, 29 Mar 2012 14:34:53 GMT
John,

there was an excellent thread about this in 2010 (which I sequestered for the very reason
you point out).  I am going to attach one of Michael Gentry's comments.  But I also wanted
to say, based on my understanding, in this case the "jokes" are not superfluous, but are at
the heart of the matter.   I agree with you totally that this issues and others should be
a part of a white paper for project managers.  However, my point in *this* thread, is that
even then, a PM is going to have problems understanding the significance of unpredictable
faulting behavior due to a fundamental lack of the cogent behavior mechanisms present in Cayenne
..... - SNORE - ZZZZZZZ - Oh, did you say something, I just dozed off - let's just use Hibernate
and make it easy, er, for me.  :)

I did research into this very issue and found, that this issue specifically is a fundamental
philosophical difference between the way these two design teams are proceeding to solve ORM
issues.  Said differently, this is *not* a rhetorical debate, but one based on fundamental
design patterns and whether they solve problems better. It appears that Hibernate is not suffering
from 'just doing it poorly', and in this the it is clear that the "Gavin Lazy-Fetch" philosophy
is not a "mistake" or "oversight", it is an intentional decision to do it differently (and
some - including me - might say: not do it at all)

	http://bwinterberg.blogspot.com/2009/08/how-to-eagerly-fetch-associations-with.html


From Michael 9/6/2010:
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 Mar 29, 2012, at 10:06 AM, John Huss wrote:

> Someone should write up a document describing the advantages (and
> disadvantages) of Cayenne compared to Hibernate.   That would be incredibly
> useful for drawing away some people from the huge community Hibernate has.
> 
> John
> 
> On Thu, Mar 29, 2012 at 4:33 AM, Durchholz, Joachim <
> Joachim.Durchholz@hennig-fahrzeugteile.de> wrote:
> 
>>> Every time I'm forced (for client projects) to use hibernate,
>>> I find myself wondering how in the /world/ it /ever/ became
>>> the dominant player in the ORM world.
>> 
>> Hehe, me too.
>> Jokes aside, Joe Baldwin has a point. I had to follow the leader myself,
>> since I wasn't allocated the time to do proper research on ORMs, and even
>> if I had, I hadn't known enough about ORMs to investigate in the right
>> directions.
>> 
>> Anyway. The statement that "having lazy fetching is a specific advantage
>> of Cayenne" is still wrong, most if not all ORMs have that.
>> You guys arguing that Cayenne does it better than Hibernate just proves
>> the point that Hibernate does, in fact, have lazy loading of relationships
>> :-)
>> 
>> (Not that I'd disagree that not having Sessions is a Good Thing. Detached
>> Sessions suck, greatly.)
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message