Hello!

We are evaluating hibernate to replace (as commonly done I guess :-) our home made O/R-Mapping.
So we are bound to the object mapping strategy we are using.

We are using a joined subclass model having an additional discriminator value in the top level
table.

To start with:
Getting a first simple hibernate use up and running using one of our object was a matter of few hours,.
A really good job done in hivbernate!
The documentation offered nearly all I needed, a pleasure to work with!
Using the DTD of the mapping file and the external docs I found the rest.

I tried the following with postgresql.

An extract from our class schema is as follows:

Common base class is PO

PO - (id: long, type: String, some other attributes)
BD extends PO: (id: long, some other attributes)
JO extends BD: (id long, some attributes)
UO extends PO: (id: long, some attributes)

The hibernate mapping was straight forward:

<class name="PO" table="x_x">
<id name="id" column="id" type="long">
<generator class="assigned"/>
</id>
...
</class>

<joined-subclass extends="PO" name="BD" table="application_xpbdata">
<key column="id"/>
<property name='extrefurl' column='extrefurl' type='string'/>
<property name='extreftitle' column='extreftitle' type='string'/>
<property name='extrefnewwin' column='extrefnewwin' type='boolean'/>
<property name='pages' column='pages' type='int'/>
</joined-subclass>

Since we are generating our Schema automatically generating the whole hibernate mapping wasn't
much of a problem.

Now the bas news:
1. We have 60 (!) sub classes, some of them having lots of attributes.
2. Using the mapping approach above I get a "statement toot long" when doing session.load(PO.class, new Long(42)) :-(

The reason is obvious when reading the generated sql statement:
Hibernate puts all attributes of all joined sub class in one big select statement which is far too big.

So I tried to solve it the same way our O/R-Mapping does it, using a discriminator column:

The changed lines are:

<class name="PO" table="x_x" discriminator-value="PO*">
<id name="id" column="id" type="long">
<generator class="assigned"/>
</id>
<discriminator column="type" type="string" force="true"/>

<joined-subclass extends="PO" name="BD" discriminator-value="BD" table="application_xpbdata">

But hibernate does not seem to support discriminator values here.
Soe my questions:

1. Does hibernate support discriminator values for joined sub classes?
2. If not is it planned?
3. From what I saw until now hibernate does match well for our project so we may implement it ourselves fpr hibernate. How difficult will it be?
4. Any ideas for work arounds ?


Many thanks for reading so far! :-)

CIao,
Carsten

1. No
2. Hibernate 2.2 ... it is the <sequential-read> feature mentioned in the Road Map
3. Actually not especially difficult (I could point you in the right direction)
4. Not really, it is a missing feature


Note that this is not an efficient mapping strategy. Sequential reads are incredibly vulnerable to the n+1 selects problem.

Thanks for your fast response!


Any pointers to what that means?


We will probably start with hibernate in a small sub project but I may come back to you after that :-)


Pointers or explanation?

Ciao,
Carsten

It means that we will be able to have mappings like:

OK that's the syntax.

To be more specific:
What is the" n+1 select problem",I never heard that phrase before.


I don't see "sequential read" to be exactly what we need.
In case of a class hierarchy of
A <- B <- C

When the discriminator value in the base class A is read there is no need
to read B AND (!) C sequentially, they can be joined
because of the discriminator values we know that B and C have to be read.

Using the "sequential read" syntax I would expect both to be read sequentially.

If a query returns 100 Bs, then I require 1 + 100 SQL queries.

quote]Using the "sequential read" syntax I would expect both to be read sequentially.[/quote]

Well, if you check the Road Map, it also includes a <join> element.


Alternatively, we could create a new subclass of AbstractEntityPersister especially for this mapping strategy.