1. "table per class" is not so bad ------------------
The documentation (chapter 10.1.1) and Hibernate in Action tell that "table per class" has the major problem that subclass columns have to be nullable.

But why shouldn't one define a subclass column "not null default X". So superclass entries get the default value assigned and subclasses must not use null for this column.

The only thing not working is "not null default null" to force a user to provide a value. This is only needed when legacy applications or ad hoc queries are working with the database.

What problem is left with "table per class" is that the table is not normalized.



2. Restrict a query to a supertype only possible with "table per class hierarchie" ------------------
There you have an additional property available in HQL with maps to the descriminator value (docu 15.7).
With class A and class B extending A you can retrieve all A excluding all B with
"from A a where a.class = A".

This is not possible with "table per class" (and I think with "table per subclass" neither, I didn't try) because the discriminator value is missing.

But why does Hibernate use the discriminator value here and not something like the table which is available in all kinds of inheritance technique?



3. "select count(*) from supertype" returns strange value -------------------------
It seems to count all items in the different inheritance tables separately.
When using "table per class hierarchy" it returns the correct value.
When using "table per class" it returns a List of Integers with the count in every table.
"table per subclass" not tested.

What sense does this behaviour make? Is it documented somewhere?
So the program code depends on the inheritance technique defined in the mapping files.



I think at least should the documentation point out these behaviours.

Regards
Sebastian

It doe's not have any problems, just use "CHECK(discriminator <> subclass OR subclassField IS NOT NULL )" constraint

But the documentation says so. It should be changed.


That's even better than using a default (if the database supports CHECK).