Comments 15
Зачем этот велосипед? чем тот же Flyway не устроил, умеющий гораздо больше, чем «просто обновить схему БД»
Умеет ли Flyway генерировать схему из JPA аннотаций и/или hibernate.cfg.xml? Беглый просмотр показал, что нет. Поправьте если не так.
0) автогенерация зло
1) помимо изменения схемы, частенько требуется ещё и корректировка хранимых данных
2) предоставлять приложению FULL ACCESS на схему БД зло
1) помимо изменения схемы, частенько требуется ещё и корректировка хранимых данных
2) предоставлять приложению FULL ACCESS на схему БД зло
на самом деле я так же использую автогенерацию в Hibernate, но не даю ему прав менять схему — это позволяет проконтролировать, что описанное через JPA накладывается на схему БД.
То, что для Вас это зло не значит, что это никто не использует. Для корректировки данных в моем случае используются Java-конвертеры с возможностью версионирования, которые умеют обновлять данные используя SQL и JDBC либо HQL после инициализации Hibernate.
ограничение по длине названия версионной таблицы и экранирование ее в двойные кавычки
это вызывает у вас ужас?
то уж лучше написать скрипт для обновления, чем городить такие вещи
ТС достаточно просто упростить свой код, применив уже готовый функционал: flywaydb.org/documentation/migration/java.html
Это если у Вас одна-две схемы для обновления. А если у Вас 10 схем в multi-tenant конфигурации, то ручной труд выглядит странно. Да и при каждом новом скрипте необходимо не забыть поправить create скрипт. Вы ведь предполагаете использовать SQL и для создания новой схемы, так? Описанный подход лишает необходимости делать что-либо руками (в плане обновления). Надо создать новый tenant и схему под него — нажал одну кнопку и приложение создаст и схему, и таблицы, и данные проинициализирует.
Sign up to leave a comment.
Hibernate, multi-tenancy и авто-обновление схемы БД