Воспроизведение, спящий режим и эволюция

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

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

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

Вопрос (ы):

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ура!