Supose I have a User base class and two subclasses Admin and Customer mapped as subclasses to User with the discriminators "A" and "C". Now suposedly I want to turn a Customer into Admin (I admit, not the best example, but I am sure you understand what I mean).

How do I do that since the discriminator must be save/update = false if I remember correctly. Am I missing something here ?

Thanks in advance

you're in java... impossible

you have to delete and create the new typed instance

Common, it must be a way to do that, or at least to avoid needing this. I can't just delete the Admin, what if it has a lot of foreign key constraints etc. It must be a way to solve the problem.

In a e-commerce site for example,it must be a way to turn an Order into a DeliveredOrder w/o actually deleting and recreating it (It has OrderItems attached etc. you mean I have to delete them too, create the DeliveredOrder and add the orderItems to it)... I mean I already used it that way but ... I think is kind of freacky. Isn't there a workaround or even "the right way" for something for this ?

DeliveredOrder should be a business state not a type... be carefull with inheritance meanings!

if you're domain model is broken, you can do this with a jdbc workaround but be carefull with first and second level cache.

ok, so maybe DeliveredOrder was not a good example, but there are many valid examples where you might need to update the type of your object. For example, you might have a Client object and a VIPClient sub-class defined as a client with at least 10 orders within a year, plus a whole new set of properties. So you want this guy saved as a Client, and he then becomes a VIPClient sometime down the road...in general, you might not know the type of your client until more information is provided down the road...like age, or region, etc...but you still have to persist in the meantime.

In any case, this seems like a big and unecessary limitation in Hibernate.

One work around is to have B ( the sublass of A ) have its own .hbm.xml file, without specifying that it is in fact a sublclass of A. The mapping for B can have a discriminator, but the mapping for A will not.

So if you update the discriminator columnd via class A, you can then read it back as B. The shortcoming, of course, is maintaining a duplicate mapping file for A and B ( minus the discriminator declaration ).

Use JDBC to update the discrminator.

Thanks Gavin. I suppose I have to pay special atention to second level cache if I use one, isn't it ?

Sure, you should perform manual eviction, using the APIs that are exposed by Hibernate for this.

It just means Admin and Customer are not User subclasses in your model. So use single class with updatable "type" property.

hi baliukas,


for sure, we always explain people that, but when they've made the mistake, it's good to have the workaround gavin has described.

"It just means Admin and Customer are not User subclasses in your model. So use single class with updatable "type" property."

How about when I have a Regular User and Admin as a subclass. Now that the user has hanged around the site long enough to give him admin rights. And want to give him Admin rights ? I understood what the solution is, and also I agree it's ugly and it seems against the way Hibernate should be used (I will just avoid comming to this situation so I don't have to bypass hibernate session) but aren't there real life situations when this would be needed ? To determine the type of the object should I call getType() on it ? Just asking, don't want to start a fight. Sorry

This has been discussed about 20 times already. Please search the forum.

Indeed I will, thanks.

Rename it to getRole() and it will be fine.

hihi. that was funny, thanks for the humor in the last reply (the one with changing getType() in getRole()). Not the method name was a problem but my way of thinking. I'll fix the damn OO model.

After a long and painfull browsing activity (I mean really) I found this, posted by Greg Barton:

"This is an OO question, really.

The main question is: is a Teacher ALWAYS a User, and is a User ALWAYS a Person? If so, then use inheritance Person -> User -> Teacher. If a Teacher can sometimes be a User and sometimes not, use delegation. (A Teacher can contain a User object which contains all info used to access the system.)

Maybe if you thought of the User object more as a UserProfile object, that would help. (UserProfile being only the information used to access the system, not the identity of the user. (little "u" intended)) Then you have Person -> Teacher with a Person or Teacher containing a UserProfile object.
"

and after, this:

"Basically your examples fit into the "Role" (or Facet) pattern. A good example of this can be seen in security. (like operating system users, with roles like Admin, Guest, User, etc...) Each user has a different level of access defined by the roles they've been assigned, and a user can have many roles. (i.e. a user could have student, teacher, or principal level access...or all three, though that would probably be redundant)

So, in your case, you could have a Person object with potentially many (aggregated) Roles. (Teacher, Student, Principal) When the Person accessed the system, their Role list would be checked and their access level determined."

Thank you Greg Barton for thislike I said, I'll fix the damn OO model :-).
And I'll get a job in constructions maybe. not as an architect, of course :-)