Прежде чем приступать к решению поставленных задач, необходимо изучить структуру используемого приложения BlogApplicaion с помощью панели Amplicode Explorer. Чтобы открыть данную панель, используйте следующую иконку:

Прежде чем приступать к решению поставленных задач, необходимо изучить структуру используемого приложения`BlogApplicaion` с помощью панели Amplicode Explorer. Чтобы открыть данную панель, используйте следующую иконку:

Панель выглядит следующим образом:

Чтобы проанализировать приложение в контексте используемых фреймворков и библиотек с помощью панели Amplicode Explorer, нажмите на значок стрелочкирябом с именем проекта, чтобы развернуть его. Здесь мы можем узнать, какие модули подключены к нашему проекту, что из себя представляет слой данных, какие эндпонты доступны, а также какие файлы для развертывания приложений уже есть в проекте.

Чтобы проанализировать приложение в контексте используемых фреймворков и библиотек с помощью панели Amplicode Explorer, нажмите на значок стрелочкирядом с именем проекта, чтобы развернуть его. Здесь мы можем узнать, какие модули подключены к нашему проекту, что из себя представляет слой данных, какие эндпонты доступны, а также какие файлы для развертывания приложений уже есть в проекте.

* Выполнить команду`flywayBaseline`, чтобы отметить скрипт инициализации как выполненный

По итогу выполненных действий команда будет успешно выполнена, системная таблица Flyway будет добавлена в базу данных, при этом в ней будетсожержаться информация о выполненном файле миграции. Выполнение первой задачи на этом завершено.

По итогу выполненных действий команда будет успешно выполнена, системная таблица Flyway будет добавлена в базу данных, при этом в ней будетсодержаться информация о выполненном файле миграции. Выполнение первой задачи на этом завершено.

* Выберите**Entity Attribute**

* Введите тип (**String**) и имя (**text**) для атрибута

* Нажмите**OK**

* Еще раз вызовите окно**Generate**

Перед сохранениемchangelogфайлов можем еще раз убедиться в их корректности в окне предпросмотра.

Перед сохранением файлов миграции можем еще раз убедиться в их корректности в окне предпросмотра.

Кстати, есть еще один скрипт, который мы упустили. Это скрипт удаления индекса из таблицы`Users`в секции**Ignored**.

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

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

Оба changelog файла успешно сгенерированы и включены в наш основной файл`db.changelog-master.xml`.

Остается только выполнить скрипты и накатить изменения в базу данных. Конечно же, самым правильным подходом к применению скриптов миграции будет настройка Flyway плагина для Maven или Gradle, т.к. он в любом случае понадобится во время настройки CI/CD pipeline. Но, чтобы не отвлекаться на эту задачу на данном этапе, в рамках данного гайда можно воспользоваться действием**Flyway Update** в Amplicode и накатить скрипты без предварительной настройки плагина, отложив эту задачу на потом.

Оба файла миграции успешно сгенерированы. Выполните их, используя команду`flywayMigrate` и проверьте статус исполнения командой`flywayInfo`.

При выборе данного пункта из меню появится следующее выплывающее окно. Нажмите в нам кнопку**Update**.

Миграция прошла успешно.

Все скрипты выполнились успешно, а информация об их успешном выполнении была записана в таблицу`databasechangelog`.

Модифицируя JPA модель, мы забыли сделать атрибут`text` для сущности`Comment` обязательным.

Исправить эту оплошность довольно легко.

Для этого, воспользуйтесь панелью Amplicode Designer и пометьте атрибут как обязательный:

Однако, засорять проект множеством Flyway changelog файлов нежелательно. К тому же, данный скрипт относится именно к changelog файлу, содержащему скрипты, связанные с созданием таблицы`Comments`. Благодаря тому, что Flyway исполняет и фиксирует исполнение именно changeset'ов, из которых состоит changelog файл, а не исполнение всего changelog файла целиком, мы можем дополнить существующие changelog файлы новыми changeset скриптами. Amplicode хорошо знает про подобную возможность и позволяет догенерировать необходимые скрипты в существующий файл.

Для этого:

* Откройте нужный нам changelog файл и обратитесь к меню**Generate** от IntelliJ IDEA и выберите пункт**Flyway Diff Changes** от Amplicode.

* В открывшемся всплывающем окне нажмите**OK**.

Новый changeset будет добавлен в существующий changelog файл.

* Накатите изменения (как показано выше) и проверьте таблицу`databasechangelog` через pgAdmin.

Хорошей практикой при разработке Spring Boot приложения и использованием системы версионирования баз данных является применение возможностей валидации соответствия JPA модели и схемы базы данных при помощи Hibernate. Путем использования свойства Hibernate`spring.jpa.hibernate.ddl-auto` со значением`validate` мы можем обеспечить соответствие JPA модели и схемы базы данных.

Если приложение запущено без проблем, лог должен выглядеть примерно следующим образом:


Столь же важно отметить, что в случае несоответствия JPA модели и схемы базы данных Amplicode сообщил бы о проблеме и дал бы возможность решить ее прямо из stacktrace.