Play, Hibernate и Evolutions

Question

У меня нет опыта работы с такими инструментами, как Liquibase и аналогичными. До сих пор в способе, которым я обычно управлял развертыванием в приложениях, использующих Hibernate, использовался ручной SQL для изменения таблиц, поскольку они были довольно простыми приложениями (сложные не использовали его ... не спрашивайте, пожалуйста: P).

Я хотел использовать Evolutions в игре, но я вижу, что он сильно конфликтует с Hibernate в разработке, что делает его болезненным, а не реалистичным вариантом. В разработке Hibernate управляет всем легко, поэтому нет смысла использовать Evolutions, но мы хотели сохранить структуру (файлы), чтобы упростить миграцию приложения в производственном режиме. Но из-за столкновений он не выглядит достойным.

У Liquibase был модуль Play, но он, кажется, был прекращен с момента выхода Evolutions (интересно, почему, как я полагаю, это будет удивительно работать с Hibernate).

Вопрос (ы) будет:

• Как вы управляете миграцией баз данных приложений в рабочей среде?
• Какую обычную процедуру / шаги вы используете, когда ваша модель меняется между выпусками, и вам приходится развертывать в производство?
• Какой-либо конкретный инструмент или особенность Hibernate, который мы пропускаем, или просто устаревшая таблица SQL Alter и т. П.?
• Ориентируясь на Play Framework, как вам это удается?

Answer 1

Часто случается, что приложение имеет два этапа в своем жизненном цикле - начальная разработка и постпроизводственное «обслуживание».По моему опыту, все большие изменения в базе данных происходят на первом этапе.Позвольте себе проявить гибкость, полагаясь на Hibernate, затем, когда вы отправляетесь в производство, вы берете дамп схемы, запускаете его в производство с помощью Evolutions и управляете своим DDL оттуда.

Во второй «фазе»(Я ловкий парень, я ненавижу слово ;-)), изменения схемы часто включают в себя также DML, потому что вы должны рассчитать начальные значения для новых столбцов и так далее.Кроме того, вы, как правило, будете тратить больше времени на кодирование, чем на изменения схемы, так что весь процесс ручного управления становится немного менее болезненным :).

(Сказав это - я бы хотел лучшей интеграции между Evolutions и Play / Hibernate, например, иметь возможность записывать DDL, который Hibernate выплевывает в каталог evolutions)

Answer 2

Ну, вы задаете очень хороший вопрос. Я боролся с этой проблемой на Grails, так что у меня нет на самом деле решения, но некоторые мысли. Я начну со сравнения эволюций с Liquibase:

1. Liquibase является зрелым решением, даже если плагин больше не находится в разработке, основная библиотека - это он. Поэтому я думаю, что это приемлемое решение.
2. Если вы используете Evolution, у вас есть один большой недостаток по сравнению с liquibase: вы должны писать свой SQL напрямую, поэтому сценарии зависят от вашей системы баз данных. Подумайте о логических значениях и представлении в разных базах данных. Таким образом, вы потеряли выгоду, которую дает вам Hibernate.

Теперь к общей проблеме. Я думаю, у вас есть варианты:

1. Пусть Hibernate обработает структуру базы данных для вас. Только в тех случаях, когда Hibernate не может выполнить эту работу, вы используете жидкость или эволюцию. К сожалению, вы можете столкнуться с некоторыми проблемами, если у вас есть сложные сценарии обновления. Как бы вы ни победили, ваше развитие будет быстрее.
2. Вы игнорируете все DDL-функции из Hibernate и делаете все с жидкой базой или эволюцией. Это самое надежное и надежное решение, но, очевидно, у вас гораздо больше работы в разработке.

Так, какова моя рекомендация? Я бы попробовал следующий подход: Разработка с распределенной системой контроля версий, такой как bzr или git. Тогда используйте feature-ветки. Используйте для ветвей функций всегда функцию гибернации. Перед тем, как объединить вещи в ствол, создайте сценарий liquibase. Эти сценарии могут быть созданы с помощью liquibase с некоторыми ручными настройками). Таким образом, вы можете разработать функцию очень быстро и всегда иметь надежное решение 2. Однако помните, что это не проверенный подход в большом проекте. Я тестировал эту стратегию только с Hibernate и Liquibase в небольшом проекте - он отлично работает.

Так что было бы здорово получить обратную связь.

Answer 3

Относительно того, что Hibernate выплюнул SQL, чтобы вы начали использовать Evolutions или Flyway, взгляните на это: http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/toolsetguide.html#toolsetguide-s1-6

РЕДАКТИРОВАТЬ: я фактически сделал плагин для начальной загрузки вашего сценария миграции. Я думаю, что это может быть полезно для большинства людей, которые сталкиваются с этой темой: http://web.ist.utl.pt/~joao.a.p.antunes/2014/08/09/play-2-2-x-jpa-hibernate-database-migration

Ура!