When we started using Hibernate 2.x, my team and I encountered a problem dealing with our table-per-hierarchy mapping. Basically, we are looking for a way in Hibernate 3.x to force the discriminator column to be checked/changed at each update.

Here is a hypothetical situation:

School Object contains an Array of People Objects. Student and Teacher Objects extend People Object. People, Student, and Teacher share a single database table that uses a String discriminator value.

There exists the opportunity that a Student will become a Teacher. We cannot (for the scope of my project) delete the Student and insert it as a new Teacher. Therefore, we want to take the People fields from Student, put them in a Teacher object. We want to then take the key from the Student object and assign it to the new Teacher object.

Now, when we do a update (or saveOrUpdate) on the Teacher Object, all of the Teacher fields get persisted to the database but the discriminator value never changes. So when you go to retrieve the object from the database you get a odd mish-mash of values.

Now, in Hibernate 2.x we over came this problem by taking the hibernate source code and modifying the generateUpdate() method of one its single-table-class persister (I forget the name off the top of my head). Basically we forced it to include the discriminator in the updates.

Now that we have upgraded to Hibernate 3.x we have to go back into the source code and muck-around to get it to do what we want it to do.

I was hoping that maybe someone knows a better work around or solution to this problem.

Thanks

I'm right with you on this one...it's eating my lunch. I have a object that needs to evolve to a subclass, and deleting is re-adding is a no go because of related data that cannot cascade. I simply need a way to update the discriminator column for the evolving object. Of course I can always hack around it, but I shouldn't have to.

tell me how you would transform your persistent instance of a Student to a Teacher in memory in your VM and i will add the feature of changing class in Hibernate for free ;)

Until then: To change the discriminator, use raw jdbc.

Currently I instantiate a new object based on the subclass, passing the old object into the constructor of the subclass. I then set the values of the subclassed object equal to the values of the original object. I add values to the new subclassed object based on its new evolved state. Now if I could only save it back to the database....

In observing what happens in the real world, in the Student/Teacher scenerio is that the Person evolves from one state to another. We don't kill the Student and then revive them back as a Teacher. We don't go to the file cabinet and burn all the old records and recreate the new records on clean sheets of paper with Teacher chosen as the type.

Now I completely understand the point you make about transforming a persistent instance in memory in your VM, but that doesn't help us solve the real world problem in a realistic, clean way.

I have read the same reply you gave, max, by other Hibernate members to other related posts and I grant you the point, but again it doesn't deal with reality of solving the problem.

If using raw JDBC IS the answer, so be it, but is there not real discussion on how to solve the problem of evolving state? Or are the rest of us all just a bunch of intellectual inferiors who are trying to force a round peg into a square hole?

This is a good natured discussion ;o)

if evolving state requires you to evolve types then don't use Java.

you are putting a round hole into a square peg ;)

You analogy is simply not possible in java. You cannot go from being one type to another, you *just* are one type - period. Its actually a terrible boring life to be a java class ;)

using raw jdbc *is* the solution since you are already doing a hack by converting the type.

I imagined the folowing: having a base class in table A and using joined-subclasses to subclass B, C, D etc...

Every A could become a B, a C or both.

It's a very convenient model to develop extension modules as they all share the same key in A.

however, I am still trying to figure out if this is possible as hibernate generates either two INSERT statements or two UPDATE statements while I need an update for the A and a create for the joint table A-B.

I know I could do row jdbc but I had rather use hibernate directly.

Any suggestion from hibernate team?

what part of my postings did you not read ? :)

use raw jdbc for this if you really need it.

And yes, that is the message from The Hibernate Team.

So your answer applies also to joined-subclass ?

yes an instance of a class *cannot* change type, thus we cannot support nor recommend it.

Actually, this seems to be problematic when a table has more than one discriminator, as only one of them will be set (further updates on the same row will not include the other discriminator columns).

Is that correct?

huh?

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