I have been the one to come in and fix things a few times in my career.
I have made it work every time, but it has rarely been fun. My point is
that Hibernate makes it easy to think you are doing the right thing, but
you aren't.
But if you want to believe, feel free to do so. I'd say we should just
agree to disagree.
Peter
On 14/07/10 23:11, jitesh dundas wrote:
I dont think so..It is actually our way of implementing hibernate..Are
you sure that the performance based issues and the tuning parameters
are being handled properly..
BTW, how many softwares do you know that do not have issues of 1 sort
or the other.
In this case, I think it is more of our implementation rather than
that of hibernate...
Regards,
jd
On Wed, Jul 14, 2010 at 6:20 PM, Peter Becker <peter.becker.de
<http://peter.becker.de>@gmail.com <http://gmail.com>> wrote:
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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[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]
<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.