I know this doesn't make much sense but... is it possible to change the subclass type of an entity?

I.e.: can I manually change the value of the discriminator in the line for that entity? I tried creating a new instance and setting it the id of the object I want to replace, but since I previously needed to load the same object in the session, hibernate does complain that a different object with the same id was already loaded.

Note: the "object already loaded" problem can be solved by using session.evict, but it seems that the instance type is not saved on update...

you can try to delete first a recreate with the appropriate type + forcing id (be carefull with cascade...)

If you can't delete the object, you can try evicting it from the session, updating the discriminator using plain jdbc, then reloading the object.

Hibernate does not do anything you can't do in your java object model. Objects just don't suddenly change their type in java, and its just the same in Hibernate. I suggest you change your class model. This has been discussed in a lengthy thread sometime ago, search for it if you want more info.

I agree with you, it's absolutely reasonable: I had already decided it is better for me to change my model. Thanks anyway.

A bit too ugly as a solution, for me, but thanks anyway! ;)

I hear what you're saying, but it's not really a fair point since the Object and relational worlds have different limitations, and therefore need to different features in order to achieve the same functionality.

Namely, in the object world if I have B as sublcass of A, I can make a new instance of B, that has the same ID property as some existingin instance of A.

In the relational world, I simply can't add a new row to a table that has the same ID as an existing row, so I have to delete the "instance" of A before I can create a new instance of "B". This is why you need to be able to "change types" in the relational world, even though you can't do it in Java.

Well, do it in the relational world by using JDBC.

yeah, but you also have to worry about the Hibernate caches, as someone pointed out earler, and you can't do that using JDBC...so some messy combination of jdbc update and hibernate evict calls is required.

how about allowing a "where" attribute in the subclass element, much like it exists in the class element? That way, the purists can keep their immutable discriminator while allowing a workaround using the where clause on an updatable property as the filter for the subclass. The one caveat would be that the where clauses in class and subclass could conflict ( e.g. A = foo, and A != foo ), but that could be considered user error.

My take on this was to call:
session.evict(oldObject);
session.replicate(newObject, ReplicationMode.OVERWRITE);

Some information gets updated but not the discriminator, which really I think is a bug. The code seems to check the id to determine if an update or insert is required, but doesn't for an sql update for the discriminator column.