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
