| Цитата |
1 вариант - наиболее корректный с точки зрения работы с данными. Как я понимаю копируем нужные поля и потом уже удаляем и добавляем. |
можно, но primary key в этой таблице является forein key в другой. Как бы не хорошо удалять, cascade пока не стоит, но как-то душа у меня не лежит
| Цитата |
2 вариант - возможны проблемы из-за кэширования - я бы не рискнул бы его использовать. |
кеширования кем ? СУБД или хибернейтом ?
Кеш СУБД тут проапдейтится, для СУБД нет разницы от кого пришел запрос
Если имеется ввиду кеш Хибернейта - то Хибернейт должен учитывать, что некоторые запросы могут ити мимо него вообще, то есть совсем с другого клиента.
| Цитата |
3 вариант - вимательнее посмотреть на проектирование - с чего это вдруг надо менять класс объекта. |
да, согласен, резонно
почему вздумалось менять ? Опишу архитектуру/логику.
Есть некие параметры. Они составлены в дерево. Соответсвенно, некоторые параметры абстрактные (узлы дерева) - по ним нет никаких значений. По параметрам-листьям есть значения.
Понятно, что в классах параметры со значениями наследуются от абстракных параметров, имея свою логику (например логика проверки значений парамеров, типа параметры попадают в какой-то диапазон и т.д.)
Почему нужно менять класс ? Дерево параметров было набито руцями, то есть дискриминаторы были изначально неверно проставлены - захотелось сделать возможность редактировать эти параметры. Но прихожу к выводу что это будет overengineered, т.к. проставить дискриминаторы можно и руцями, а в дальнейшем оно будет совсем-совсем нечасто меняться.