>
> Anyhow: Who knows Hibernate and can comment on its
> usefulness as a model?

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)

Here's some basic example code for you to look at anyhoo.

Java class:

class Cat

  private long id;
  private String name;

  public long getId() {
    return this.id;
  }

  /** note that this is the id field that Hibernate uses, it should not 
be directly setable by external clients - hence private */
  private void setId(long id) {
    this.id = id;
  }

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }
}

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.

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...

/**
 * @hibernate.class
 *    table="cat"
 */
class Cat

  private long id;
  private String name;

  /**
   * @hibernate.id
   *    column="cat_id"
   *    generator-class="sequence"
   */
  public long getId() {
    return this.id;
  }

  /** note that this is the id field that Hibernate uses, it should not 
be directly setable by external clients - hence private */
  private void setId(long id) {
    this.id = id;
  }

  /**
   * @hibernate.property
   *    column="name"
   */
  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }
}

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.

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).

Right now, I'd say that Hibernate3 + Spring + J2EE services are very 
useful when you have to actually build an enterprise application (access 
n datastores of various forms across different locations etc).  But 
ActiveRecord (and the rest of Rails+Ruby) is a much more efficient (in 
terms of coding time) way of getting to 80% of the functionality of 
Hibernate3/EJB3 that it doesn't make sense to use Hibernate in all cases.

Erm wandered of the point there a little.

Summary
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.

Kev