Юзаю хибернейт. 
Есть иерархия классов, сущности записываются "table per class hierarchy" (то есть всю иерархию в одну таблицу).

Отличие классов - только в значении самого дискриминатора.

Задача - мне нужно изменить значение дискриминатора, чтобы  при последующем чтении получить другой класс по изменённой записи.
Проблема - при апдейте хибренейт не изменяет значение дискриминатора ни при каких условиях (то есть сгенерированный SQL не содержит изменение поля дискриминатора). 
Пробовал в том числе создавая сущность другого класса из иерархии и копируюя в неё данные из первой сущности с последующим апдейтом созданной сущности другого класса.

Порылся в вебе, есть 2 варианта:
1) удалить старую сущность (удалить запись из таблицы), вставить новую с другим классом
2) выполнить свой update-SQL для апдейта значения дискриминатора вручную

Никаких вариантов получше нет?

1 вариант - наиболее корректный с точки зрения работы с данными. Как я понимаю копируем нужные поля и потом уже удаляем и добавляем.
2 вариант - возможны проблемы из-за кэширования - я бы не рискнул бы его использовать.

3 вариант - вимательнее посмотреть на проектирование - с чего это вдруг надо менять класс объекта.

Абсолютно согласен.
Может просто стоит создать сущность другого типа по образу и подобию и положить в таблицу? а старую можно и грохнуть...

to barracuda477 приведите пример логики, в связи с которой возникла такая задача

можно, но primary key в этой таблице является forein key в другой. Как бы не хорошо удалять, cascade пока не стоит, но как-то душа у меня не лежит 


кеширования кем ? СУБД или хибернейтом ?
Кеш СУБД тут проапдейтится, для СУБД нет разницы от кого пришел запрос
Если имеется ввиду кеш Хибернейта - то Хибернейт должен учитывать, что некоторые запросы могут ити мимо него вообще, то есть совсем с другого клиента.


да, согласен, резонно

почему вздумалось менять ? Опишу архитектуру/логику.

Есть некие параметры. Они составлены в дерево. Соответсвенно, некоторые параметры абстрактные (узлы дерева) - по ним нет никаких значений. По параметрам-листьям есть значения. 
Понятно, что в классах параметры со значениями наследуются от абстракных параметров, имея свою логику (например логика проверки значений парамеров, типа параметры попадают в какой-то диапазон и т.д.)

Почему нужно менять класс ? Дерево параметров было набито руцями, то есть дискриминаторы были изначально неверно проставлены - захотелось сделать возможность редактировать эти параметры. Но прихожу к выводу что это будет overengineered, т.к. проставить дискриминаторы можно и руцями, а в дальнейшем оно будет совсем-совсем нечасто меняться.