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.

Reply via email to