Say I have a Class hierarchy, where Parent and Child both extend Person.

I have the mapping set up so that the whole hierarchy persists to one table, called Person.

I persist an instance of Person to the table.

At some point I obtain further information about this particular Person, and so now want to convert to the Parent class and persist these additional details.

I load the Person instance, and then construct an instance of Parent, passing the Person details in the constructor of Parent.

I now want to save this Parent instance.

Here's where I am having problems:

- If I try session.save(parent), this inserts a new row into the table with duplicate data except for a new generated ID and the correct new dicriminator column value for the Parent subclass type

- If I try session.saveOrUpdate(parent), this gives me this exception:
net.sf.hibernate.impl.SessionImpl Could not synchronize database state with session
TRAS0014I: The following exception was logged net.sf.hibernate.HibernateException: SQL update or deletion failed (row not found)

... presumably because it is attempting a select (before the update) on all the columns for the Parent subclass, which does not yet exist in the database.

To attempt to work around this, I have found I can delete the existing Person, and the save the new Parent instance. This works ok, but the newly inserted Parent has a new generated ID, which breaks any existing relationships that the original Person instance had.

What is the correct approach to this problem?

Thanks,
Kevin Hooke

It sounds like you're trying to implement a Smalltalk "become" operation, where a single object retains its identity while changing its class.

This is not supported in Java and it makes sense that it would not be supported in Hibernate.

The cleaner thing to do would be to create your new Parent object, with a new identity, and then update all relationships to reference the new Parent object. Then delete the old Person object once it is unreferenced. (Doing all this in a single transaction, if possible, of course....)

Cheers!
Rob

Or model the whole shebang as a composite pattern:

http://forum.hibernate.org/viewtopic.php?t=926542

Thanks for the suggestion, but I'm not sure this scenario really fits the Composite Pattern: i.e. I don't have any object composition in a tree structure and/or need to represent this relationship as a part/whole hierarchy.

Unless I am misunderstanding the intent of the pattern?

What I am really looking for is an approach to casting instances down the class hierachy tree and updating the persisted instances accordingly:
- at some point I have a Person instance
- at a later time, I gain further information about this Person which allows me to classify them as a Parent or a Child (which are both subclasses of Person)

The only approach to this with Hibernate I have found so far is to delete the Person, instance a Parent or Child instance, and then save again in this new state.

This seems like a very clumsy approach, and I am sure there must be a better way of doing this.

Another approach would be to rework my class relationships so that this 'type' of person is an attribute of a Person, instead of a subclass, but this does not seem a very pure OO approach.

Thanks,
Kevin Hooke

I'll admit that my solution to this exact problem is a hack, but here is a solution, for what its worth:

I use a joined-subclass for a setup similar to above

Person
|
-- User
|
-- Interviewer

a user may become an interviewer late in their career.

there would be hundreds of items i would need to update to delete the user and create an interviewer

so i create a simple prepared statement to add a row to the interviewer table with the appropriate id

not pretty, but it works.