Стратегии обработки обновлений в существующих классах сохраняемости JPA

Question

Мы делаем проект, в котором мы планировали использовать JPA Persistence.Мы думаем, что после запуска проекта существует небольшая вероятность того, что изменения в модели данных могут потребоваться.

Мой вопрос заключается в том, какие существуют различные стратегии для обработки таких изменений.В частности, у меня есть следующие вопросы:

1. С обновленными классами JPA, как лучше всего включать их в существующую схему базы данных?

2. СJPA, есть ли рекомендации по архивированию старых данных, обновлению схемы базы данных и повторной миграции базы данных в новую схему?

3. Какие существуют различные виды изменений (в широком смысле)что сделает такую ​​миграцию невозможной?

Answer 1

Вы также можете взглянуть на эту платформу: http://flywaydb.org

Рекламируется как: "Инфраструктура гибкой миграции баз данных для Java"

По моему опыту, миграции не являются проблемой (hibernate может делать их автоматически), но откаты есть, если вы имеете дело с деструктивными изменениями.Например, если вы удалите столбец, откатить это изменение невозможно, если только у вас не скопированы данные из этого столбца.Лучший способ сделать такие резервные копии, вероятно, зависит от вашего поставщика БД.

Answer 2

В RHQ (http://rhq -project.org / ) у нас есть некоторые dbutils, у которых есть описание схемы в XML, которое служит для заполнения начальной схемы в пустой базе данных, а затем другой XML-файл, который регистрируетсяизменяется в этой базовой схеме как отдельные "diffs" операторов DDL и DML.

Всякий раз, когда изменяется класс JPA (соответствующим образом для схемы), обновляются оба файла XML.При следующем запуске установщика он просмотрит существующую базу данных, соберет ее версию и затем воспроизведет все шаги обновления от версии в БД до самой последней.

Этот код dbutils доступен в git .

Существуют и другие структуры, такие как liquibase , которые могут вам помочь.