We have a situation where we want to switch the java type of a persisted object from a superclass to a subclass. We are using a one-table-per-hierarchy strategy for these classes. We have employee objects that at some point after their initial persistence need to be converted to principal investigators. Is there any way to do this?

The pertinent mapping (with non-essential elements edited out) follows.

Hibernate version: 2.1.9

Mapping document:

[I work on the same team]

I should add:

1) The underlying employee table has many other tables holding FK references to it.

2) The underlying table uses a natural key, the employee ID, as its PK.

There is no "hierarchy" in model if you need to update "discriminator", use it as simple field.

We can't see how to do that since there is no property in the class corresponding to the discriminator. Therefore there is no setter for the discriminator property.

Wayne

use raw jdbc for this - changing the discriminator of an object is not semantically well defined, how would you change the class of an object ? ;)

If we use raw jdbc, we lose dbms transperency. In a regular class heirarchy, I would create an instance of the subclass and copy in the supoerclass properties. Unfortunately, in a Hibernate heirarchy, you cannot create the subclass instance with the same identity without deleting the original (database primary key constraints). If we had access to the discriminator, then changing it's value would be tantamount to the instance creation above.

Wayne

Just add "type" property or something like that and use it without enheritance, if you need to change object class then this model is wrong in JAVA, change it.

When creating a new instance of the subclass, you would create a Java object that has nothing to do with the original object. References to the original object would not be changed to the new one, and you wouldn't have a way in Java even to find all those possible references. In short: Changing the subtype of an object isn't supported in Java, and there is no way around this.

Getting a new id created for the new object therefore just mirrors the Java object identity situation. Foreign keys pointing to the old row won't change automatically to the new one. However, you even have the possibility to retrieve all objects that point to the old one from the database, and to re-associate them to the new one.

Of course, in java, if I had the following situation. I have 2 Person Objects, dad and son. They are just Person objects. If I want to have a Parent object and an Offspring object (both subclasses of Person), I can create them separately. Then I can copy in all of the fields of person into the objects and then populate the parent property of offspring (son) with a reference to dad and populate the offspring collection of parent (dad) with a list, set, ... with at least son (and maybe some more stuff). Then I can replace the dad and son references in the object graphs with the new dad and the new son. Then I am done. We are willing to do that work. The problem with relational database is that the assigned key (Employee_ID) means that we cannot create the new objects until the old object is gone which turns all of its children into orphans (constrained by the database). If we just had access to the discriminator, this problem would disappear and all would be well.


Wayne