Robert,
Thanks again for your insight (and mapping some of the technical terms).
Just as a random test of current faulting behavior I googled more on Hibernate and found:
http://bwinterberg.blogspot.com/2009/08/how-to-eagerly-fetch-associations-with.html
It appears that the Gavin-lazy-fetch philosophy was not an oversight or legacy-anachronism (i.e. comparing new to old), it appears it is in fact an intentional and well considered design pattern.
This *may* have something to do with their adoption of the "Session" design pattern vs the more traditional and mature "ObjectContext" pattern. I don't really know, but I disagree on a fundamental level with their approach.
The more I think about this the more that the Cayenne vs Hibernate faulting-design differences mirror the C/C++ vs Java Memory Management evolution. Java aggressively addressed the "intelligent" Garbage Collection problem and assigned the responsibility to the JVM (which has evolved to the point at which the "best practice" for the programmer is "don't mess with it", while C++ still has not even officially recognized it as a problem.
This faulting behavior appears to be a serious flaw in the Hibernate design, and one that is easily demonstrated as an advanced ORM feature of Cayenne. I agree that this almost reduces the concept of "relationships" to useless in Hibernate. How can Hibernate possibly get away with dismissing post-session lazyfetchexceptions as anything but a serious design flaw an one that should be handled by any version-1.0 ORM?
Joe
On Sep 6, 2010, at 3:41 PM, Robert Zeigler wrote:
> I don't think you're misunderstanding. Their implementation causes me (and countless others) constant headaches.
> HibernateSession is the closest thing in Hibernate to the Cayenne ObjectContext (DataContext). But they aren't perfectly aligned.
> A session is certainly closer in sensibilities to a (managed) transaction than the ObjectContext is, although not perfectly analogous to a transaction, either. A session /can/ be held across multiple requests, and may or may not have a transaction associated with it at the current time. But the general pattern is session-per-request by default (I think seam changes this to "session-per-conversation").
>
> Robert
>
> On Sep 6, 2010, at 9/62:24 PM , Joe Baldwin 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
>>
>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Mon Sep 06 2010 - 20:12:56 UTC