Объединить автоматическое создание схемы Hibernate и управление версиями базы данных

У меня есть приложение, где Hibernate создает все мои схемы таблиц всякий раз, когда приложение запускается на машине в первый раз. Это прекрасно работает.

теперь мне было интересно, есть ли у Hibernate какой-то механизм для сохранения базы данных под контролем версий, т. е. будет ли Hibernate знать, как перенести одну схему на другую, когда я запускаю другую версию своего приложения, и Hibernate находит другую схему базы данных из более старой версии? Я как-то подумайте, что это должно быть возможно, учитывая, что Hibernate может прочитать существующую схему и сравнить схему с описанием отображения. Однако я не знаю, как я мог бы сказать Hibernate перенести старые данные, как при создании сценариев изменений, например, Liquibase / Flyway.

возможно, я не гуглил правильные вещи, так как Hibernate и versioning покажут вам много хитов по аудиту и полевым версиям, но я думаю больше с точки зрения Liquibase / Flyway управление версиями. Я никогда не рассматривал оба вместе, но поскольку Hibernate не создает скрипты обновления, а напрямую манипулирует базой данных, я не знаю, как заставить оба работать вместе.

Это первый раз, когда я позволяю Hibernate создавать мою схему вместо написания моих собственных сценариев. Я делаю это для того, чтобы использовать Hibernate Envers что делает ручное создание сценария очень утомительным. Возможно, я упускаю что-то очевидное. Спасибо за любой вклад в это материя!

Update: я должен поговорить с разработчиком Flyway сегодня, и он сказал мне, что он не будет знать о хорошем решении. Может, ничего и нет?

8
database-versioning hibernate

1 ответов

У нас была такая же проблема с нашим проектом Java/Hibernate, и мы не хотели никаких усилий по дублированию кода. Функция Hibernate "update" не является надежной вообще, LiquidBase лучше, но не 100% доказательство дурака. В итоге мы разработали простой скрипт для управления следующими процессами:

  1. " текущая " схема базы данных всегда генерируется Hibernate, против базы данных DEV напрямую.
  2. " предыдущая " схема базы данных создается ряд при набор изменений.
  3. каждый раз a миграция необходима, функция LiquiBase" diff " вызывается между "предыдущая "и" текущая " базы данных (две фактические базы данных, да, более надежно таким образом), генерируя новый набор изменений LiquiBase.
  4. этот набор изменений должен быть проверен вручную. Все наборы изменений сохраняются в управлении исходным кодом.
  5. производственная база данных имеет свою схему генерируется путем применения всех наборов изменений LiquiBase.

ключ команда в нашем скрипте читается следующим образом:

${LIQB_COMMAND} ${PREV_DB_OPTIONS} --changeLogFile=${LIQB_CHGLOG_FILE_NEW}  \
    diffChangeLog \
                --referenceUsername=${DEV_DB_USER} \
                --referencePassword=${DEV_DB_PWD} \
                --referenceDriver=com.mysql.jdbc.Driver \
                --referenceUrl=${DEV_DB_URL}

таким образом, наш процесс миграции довольно надежен, и вы не пишете код схемы дважды. Существует ручной обзор сгенерированного набора изменений в XML, но в большинстве случаев нет проблем, и это намного проще, чем вручную писать операции изменения схемы.

10