Hi,
I'd like to have your opinion on the solution to the following problem with Hibernate :

What we want basically is a parent/child relationship model with bidirectional one-to-one and one-to-many, much like in the example provided in the hibernate docs. We use a table per concrete class strategy.

Our problem however, is we don't know what is going to be the parent of an object of class C in advance (see code below). The only way I see we can go is with the "Any" type mapping. Right now we don't have a "parent type" column and this would mean considerable work. Has anybody found another solution to this type of problem? Any examples of using the many-to-any type mapping? Thanks

We have a whole bunch of business classes that extend a baseclass :

abstract Class baseclass {
int id;
int parentid;
bool hasparent;
}

Class A extends baseclass {
C c;
String d;
}

Class B extends baseclass {

C c;
String e;
}

Class C extends baseclass {
String f;
}

...

The tables are as follows :

Table A (id int, parentid int, d varchar);
Table B (id int, parentid int, e varchar);
Table C (id int, prarentid int, f varchar);

I think it is not possible to map polymorphic associations without additional "any" discriminator columns if you require "table per concrete class". This is really not a good design decision, can't you switch to "table per sublass"?

Thanks for your interest, I have looked into the table per subclass strategy.

I *think* I understand this model, and switching to that for us would basically mean to add a table baseclass (id int, parentid int) and adding an entry for every single object in the system in that table (because all objects inherit from baseclass).

That would be feasible, however we have our own o/r mapping solution in place right now that we would have to throw away. With the table per concrete class strategy, the db schema remains the same and so we can still switch between Hibernate and our custom persistence manager. This is very desirable for many business reasons.

I am also concerned with the number of table joins that strategy implies. Sometimes, we join 10 tables to find an information and performance is an issue.


The bottom line is what is the drawback of using table per concrete class with many-to-any relationship, besides it not being a good relational design? I see table 16.1 in the docs says there a few features I cannot use, but all we need really is a bidirectional link where the parent has non polymorphic child but the child has a polymorphic parent.

Thanks for sharing your thoughts

The major drawback is that a query to the superclass requires several queries to each of the subclass' tables. I think that the next Hibernate version supports UNION in some scenarios, but two SELECTs might not be as performant as a JOIN with table-per-subclass.

Yes, I already implemented the <union-subclass> stuff in the v22branch. So it will be possible to have bidirectional polymorphic associations for table-per-concrete-class in the next major release of Hibernate. However, it is still a sucky relational model.