What I blame Hibernate for is being misleading about the complexity.
Most people think it makes a developer's life easier, but my experience
is quite the opposite. It is nice and easy until you hit the errors and
performance issues and unless you understand Hibernate really well you
will hit those fast.
I consider object-relational mapping a stupid idea, but unfortunately
one that's hard to avoid in current enterprise development. Thus my
cynicism.
Peter
On 14/07/10 22:40, jitesh dundas wrote:
Precisely what I was about to say in a few minutes..Peter, you read my
mind..
It is not about HIbernate being slow or the software having issues of
redundancy. The problem is how we implement Hibernate..That said, we
need to understand how we are handlinig the xml file defnitions and
relationship mappings..
Till now, we have seen instances when functional design leads to code
level design. This is the case where the opposite holds true
also..You have to map according to the platform - a bit of reverse
engineering - and then decide the optimum performance..
large sites using cache databases is not new..Plenty of them do that -
especially in lotus notes application..The problem is the data that
you are trying to update...
Are we doing that correctly..
Let us not blame Hibernate for everuything friends..There is more than
what meets the eye..
Regardsm,
jd
On Wed, Jul 14, 2010 at 6:00 PM, Peter Becker <peter.becker.de
<http://peter.becker.de>@gmail.com <http://gmail.com>> wrote:
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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:javaposse%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
--
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.
--
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.
