On 14/07/10 21:22, Moandji Ezana wrote:
On Wed, Jul 14, 2010 at 11:45 AM, Peter Becker <peter.becker.de
<http://peter.becker.de>@gmail.com <http://gmail.com>> wrote:
On 14/07/10 19:16, Moandji Ezana wrote:
The thing I find most useful about Hibernate is that when you
have a lot of tables of inter-related data, it really
alleviates the pain of having to think about what data you
need to load for each possible workflow.
Not if you care about scalability, in which case you really need
to know what you want to fetch and how all your caching layers
work (although the caching as such can be a good feature to have).
Particularly if you reach the same object from different contexts
with different requirements, thinking about eager and lazy
fetching can get rather complicated.
True, but if you need to scale massively, you probably aren't using
Hibernate anyway. (Or are you? Anyone know of massive sites that use
Hibernate?)
I'm not talking about the Googles or Amazons. To get into this type of
problem you really need only a few gigs, if you do really stupid things
only a couple of megs will do -- if you reload all of your DB on every
request performance will degrade very fast.
I haven't seen whole DBs being loaded yet, but I have seen things pretty
close to that -- particularly in cases where eager fetching is used as
the solution to the problem of the view not being part of the Hibernate
session. I know the answer is to expand the session lifecycle to contain
the view, but that awareness doesn't seem widely spread. Depending on
your framework it is also often not trivial. Spring can do it
declaratively and knowing the right hooks most other frameworks let you
do it, but you left the realm of nice and easy that Hibernate advocates
tend to advertise.
My point really is that while Hibernate can produce nice and easy
solutions, the only way to know you have a good solution is to fully
understand what's happening. And that is not easy and sometimes not nice
either (did someone mention "object identity" yet?). That makes
Hibernate a solution that is nice and easy as long as you either don't
care at all about the potential issues or you have someone else to take
care. If you are the one who has to care you really need a very good
understanding of the OO side, the RDB side and the ORM part.
Peter
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
