Как мне управлять развитием базы данных, когда я использую JPA?

Question

Я научился играть, следуя руководству на их веб-сайте по созданию небольшого движка для блогов.

Он использует JPA и при загрузке вызывает Fixtures.Deletemodels (), (или что-то в этом роде).

Он в основном уничтожает все таблицы при каждом запуске, и я теряю все данные.

Я развернул производственную систему вроде (без оператора nuke).

Теперь мне нужно развернуть большое обновление в производственной системе. Многие классы были изменены, добавлены и удалены. При локальном тестировании, не разбирая таблицы в каждом цикле, я столкнулся с проблемами синхронизации. Когда я пытался писать или читать из таблиц, игра приводила к ошибкам. Я открыл MySQL и, конечно же, в некоторых случаях таблицы были изменены только частично и неправильно. Даже если в моей конфигурации для режима DDL установлено «создание», JPA не может «понять», как согласовать изменения и изменить мою схему соответствующим образом.

Так что я должен вернуться в оператор начальной загрузки, который уничтожает все мои таблицы.

Итак, я начал изучать эволюцию базы данных в Play и читал статью на веб-сайте Play Framework об эволюции базы данных. В статье говорилось о скриптах версий, но говорилось: «Если вы работаете с JPA, Hibernate может автоматически обрабатывать эволюции баз данных. Эволюции полезны, если вы не используете JPA».

Так что, если JPA должен позаботиться об этом для меня, как мне развернуть большие обновления в большом приложении Play? До сих пор JPA не смог правильно внести изменения в схему, и приложение будет выдавать ошибки. Я не заинтересован в потере всех моих данных, поэтому исправление dev "Fixtures.deleteModels ()" не может быть использовано в prod.

Заранее спасибо, Джош

Answer 1

Нет, JPA не должна заботиться об этом за вас. Это не волшебный инструмент. Если вы решили переименовать таблицу «клиент» в «клиент», столбец «улица» в «line1» и переключить значения столбца типа клиента с 1, 2, 3 на «бронза», «серебро», « золото ", у JPA нет возможности читать в уме и придумывать все изменения, которые нужно делать автоматически.

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

Answer 2

Взгляните на пролет . Вы можете запустить миграцию базы данных из своего кода или maven.

Answer 3

Когда контейнер JPA запускается (скажем, EclipseLink или любой другой), он ожидает найти базу данных, которая соответствует классам @Entity, которые вы определили в своем коде. Если база данных уже перенесена, все будет работать гладко; в противном случае: вероятно, это не удастся.

Итак, короче говоря, вам нужно выполнить миграцию базы данных (или эволюцию, если хотите) до запуска контейнера JPA. Очевидно, Play выполняет миграцию за вас, прежде чем Play начнет работу с менеджером баз данных, который вы настроили. Таким образом, теоретически, независимо от того, какую ORM вы используете, Play решает, когда пора ORM начать свою работу. Итак, концептуально это должно работать.

Для хорошей презентации на эту тему, пожалуйста, посмотрите второе видео по адресу: http://flywaydb.org/documentation/videos.html

Answer 4

Существует свойство с именем hbm2ddl.auto=update, которое обновит вашу схему. Я бы настоятельно рекомендовал не использовать этот параметр в производстве, поскольку он создает совершенно новый уровень проблем, если что-то пойдет не так. Впрочем, это прекрасно для разработки.