Hi,

I have to replace a self built OR layer with Hibernate. So I got to deal with a legacy database that reflects inheritance in a special way. Let me explain step by step. The inheritance hierarchy for persistent classes only allows concrete (non-abstract) classes for the "leaf classes". There are no intermediate concrete classes.

In the database are tables for all classes in an inheritance hierarchy (stopping just before the universal PersistentClass root), this includes the abstract ancestors. The tables for subclasses reference their superclass tables with foreign keys. So far, this sounds like table per subclass. But here comes the catch: The properties of the abstract classes are in the tables for the concrete classes, whereas the associations of abstract classes result in foreign keys in the abstract superclass tables themselves.

Here is an example to clarify this:



I've been thinking of using table per concrete class now and simply joining the tables for abstract classes (JPWH § 8.1.3). But, according to JPWH, this seems to be limited to <many-to-one> relationships in the abstract class tables, which conflicts with the domain model (there can also be <one-to-many> relationships).

Do you see a way to deal with this situation? If it can't be done with the mapping possibilities given by Hibernate, maybe some kind of programmatic workaround would solve this?

Hi,

probably too late for you, but maybe others in a similar situation can profit.

I once had to solve the same problem. Here's my solution:

Reading from the database

• Use the table per subclass strategy
• Add views to the database which join the association information for a superclass and it's property values
• Indicate the view instead of the "real" table for a superclass in the mapping metadata

Now reading information from the database should work! By programmatically generating a view creation script you can automate this process.

Writing to the database

This is a bit tricky. You have to use custom SQL for insert/update/delete operations in the mapping files for the superclasses. As you can't manipulate a view, you have to persist data in the original schema, the association information of a superclass in the table for the superclass, the property values in the table for the concrete "leaf class". The mapping for a superclass property has to exist both in the mapping file for a concrete "leaf class" and it's superclass (which is linked to the corresponding view). But in the mapping file for the superclass, you have to mark the property with these tags: update="false" insert="false"
This will lead Hibernate to eliminate the parameters for the properties of a superclass from an insert operation concerning this superclass. Persisting those properties is taken care of because of duplicate property mappings in the mapping files for the concrete "leaf classes". In those mapping files certainly without update="false" insert="false" tags.
Now that we have gotten Hibernate to generate only the parameters which make sense for the corresponding table of a superclass, we are faced with finding out which parameter order Hibernate is generating, because we have to rely on a certain parameter order in the custom SQL for insertion which unfortunately is not evident. So you have to try and let Hibernate (run it in debug mode) try to insert the information for a certain class and look at the parameters generated. Afterwards you can write your custom SQL code in the corresponding mapping file.

Hope this was understandable, let me know if you need further explanations.