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
>>
>>
>>
>>
>
