From: rubyhacker@...
Date: 2005-10-27T04:27:08+09:00
Subject: Re: The "perfect" ORM?


Kev Jackson wrote:
> >
> I've spent a fair bit of time with Hibernate and I can safely say that
> it is not the "ruby way" (even from the little experience I have with ruby)

Thanks for this lengthy and informative post.

There's no question that a "clone" of Hibernate is wrong for Ruby.
But my understanding is that it at least keeps its hands off the
user classes (to some extent).

> Now you have a simple JavaBean style of class, the only thing that
> Hibernate imposes here is that it seems to be easier to use id values
> that are auto-generated (long maps to number(19) in Oracle etc).  You
> can use Strings (auto generated hex values) or assign the id/primary key
> yourself.  Best practice in the Hibernate community is to let the
> database auto-generate where possible and to always use surrogate keys.

Logan Capaldo and I talked about this. I'm still uncomfortable with it,

but will probably come around. I'd still like to code it the "other"
way
first -- manually assigned primary keys. The process of doing that will
clarify it in my mind, and I will be able to see the pros/cons better.

> So yes in the raw Java code for the model, Hibernate does not
> interfere.  However at this point, you still need to map the JavaBean to
> the database table.  This is done with a (verbose) xml mapping file.  As
> these are such a pain to write, most people use XDoclet to generate the
> mapping automatically.  For XDoclet to do this, you have to sprinkle
> attributes into your Java code like fairy dust.  So the code would
> really look like...

I can tell you right now that whatever solution I end up using will not
employ XML or any XDoclet equivalent, and I hope to avoid fairy dust as
much as possible, as I am allergic to it. I'd like to centralize the
typing/mapping info as much as I can, and likewise use reflection as
much as I can.


> In Java5, the introduction of annotations allows these special
> @whatevers to be placed outside of comments.  Hibernate3 supports both
> styles (in comment and true annotations).  If you can say that these
> Attribute/Annotations don't couple themselves to your model code, then
> yes, the assertion that Hibernate is unobtrusive is true.  On the other
> hand, actually keeping the metadata in a separate file (xml mapping in
> Hibernates case), means that the turn-around on a change is fairly
> significant.  Trust me, coding up a Hibernate app without using Ant +
> XDoclet is an exercise in pain, even with Ant + XDoclet, the change
> code->deploy is still a drag.

The idea of rampant annotation is repugnant to me. So is the concept
of storing such info in a separate file.

Basically, I want the mapping info to be part of my code, but not part
of the objects I want to serialize. And I want it to be fairly
centralized rather than scattered here and there.

> There are some cool parts of Hibernate, being completely flexible on how
> you configure every aspect is probably the most 'enterprise' feature of
> it.  It allows it to be used so much more easily with legacy data
> (composite business keys, wierd table structures etc).

I guess I'm more concerned with legacy objects than legacy tables. I'm
one of those who would like to build database tables from object defs,
rather than the other way around.

> Hibernate is very good at allowing you to specify everything, but you
> pay the price with overly complex and verbose configuration files that
> *must* be in sync with your model code for the application to work -
> this synchronization issue is the achilles heal of Hibernate in my
> experience - I've wasted too much time when the server has cached an old
> mapping file instead of deploying the new one.

As I said, I'd want this mapping info stored *in* my code, but not
scattered through it, and not in my stored classes. Hopefully that is
a viable world view.

Thanks much,
Hal