I have the following:


Accountable and Party are used in several relations in the application, so I guess their mapping is mandatory. Contactable is used in the application but not in any relation, so I guess its mapping its optional.

I think the right (only?) way to map this is having Accountable as a class, and Party and SimpleParty as joined subclasses. In case I also map Contactable, I guess I should have two class mappings, one for Contactable and another for Accountable, and both would include Party and SimpleParty as joined subclasses. Am I right?

Any comments are welcome, thanks in advance, regards
Jose

I've been thinking about this issue, and I think Hibernate can't handle this kind of relationship, am I wrong? Hibernate seems to need a column in the child class/interface pointing to the table of the parent class/interface. This is impossible to acomplish if a class/interface extends two interfaces that are mapped to separate tables. So I must conclude that Hibernate doesn't support mapping of hierarchies of interfaces where you don't have a tree kind of hierarchy.

I guess the only solution here is to drop the mapping of one of the root interfaces (this implies I won't be able to use that interface in any persistent relationship) and use the other one as the root of the mapping, am I right?

Thanks, regards
Jose

no - you just need to map the concrete classes AFAIK.

At some point you need to decide what kind of physcial data your class maps to - and thus you can't have "diamon" inheritance

Are you sure? I thought you had to map every class/interface that could participate in a persistent relationship.

Let's complicate it a bit to see what I'm telling you... let's say I have the following:

Lest's say you only create mappings for concrete classes (Company and SimpleParty). Now you have some many-to-many association where the end of the association points to Contactable... how would Hibernate handle this, if possible?

I now you'll tell me that polymorphism is limited with the table-per-concrete-class strategy, but then let's suppose we use a table-per-class strategy (joined-subclass)... I cannot imagine how would this be handled in the case of the party table, as you should have a foreign key pointing to two tables, contactable and accountable.

And finally we have the table-per-class-hierarchy strategy... what should you do? A contactable table and an accountable table? Where would party objects be stored? Would Hibernate save the data in both tables when updating SimpleParty objects?

Best regards
Jose

I've been re-reading the inheritance mapping chapter and the any mapping in the Hibernate reference. You are right, I don't have to map the interfaces, I could use many-to-any instead of many-to-many and any instead of many-to-one, using a table-per-concrete-class strategy.

Anyway I get some nasty side effects: there are some places where some of those interfaces are used in bidirectional associations (may-to-one / one-to-many), and it seems I'm out of luck here, as one-to-many is not supported in this case. I also guess that performance would be worse in this case.

Is it possible to use the table-per-class-hierarchy or the table-per-subclass strategies in such a case? How?

Best regards, thanks
Jose