Таблица журнала изменений базы данных не создается в среде Postgres для Liquibase - PullRequest
Новая
       61

Таблица журнала изменений базы данных не создается в среде Postgres для Liquibase

0 голосов
/ 27 мая 2020

Зависимости Maven; Версия Spring Boot: 2.2.3.RELEASE Версия Liquibase Core: 3.8.5 Postgresql версия: 42.2.9

У меня есть приложение Spring Boot, которое работает с базой данных PostgreSQL 11, которая продемонстрировала новое поведение, не замеченное ранее. Когда я запускаю команду обновления, таблица databasechangelog не создается внутри моей активной схемы, даже если создается таблица databasechangeloglock. Это, конечно, приводит к сбою прогона, поскольку отношение не существует. Тем не мение; Я не контролирую создание этой таблицы и никогда не контролировал ее. Таблица, используемая для автоматического создания, аналогична таблице блокировок, но теперь это не так.

Вот как я настроил свои 2 основных объекта для базы данных и Liquibase для использования командой обновления. 

private void setDatabase() {
    if (hasConn) {
        try {
            database = (Database) Class.forName("liquibase.database.core.PostgresDatabase").newInstance();
            database.setConnection(new JdbcConnection(getConnection()));
        } catch (InstantiationException | IllegalAccessException | ClassNotFoundException e) {
            log.error("Could not return Liquibase Database Object");
            log.error(e.getMessage());
        }
    } else {
        log.warn("Connection Object not yet set!");
    }
}

private void melt() {
        this.liquibase = new Liquibase(getDatabaseChangeLog(), new ClassLoaderResourceAccessor(), getDatabase());
}

private void drinkUpdate() throws LiquibaseException {
        this.liquibase.update((String) null);
}

Недавно я изменил это приложение, чтобы оно стало частью многомодульного проекта Maven, который изменил все ссылки на версии, которые я использую, на основе нового родительского POM.

Мой вопрос: , видел ли кто-нибудь такое поведение раньше и связано ли оно с версиями банок, используемых при обработке? Почему при обновлении генерируется таблица databasechangeloglock, а не таблица databasechangelog? Также; похоже, что таблицы databasechangelog генерируются в моей схеме publi c просто отлично для каждой из моих баз данных, которые я генерирую ... только не в моих объектах пользовательской схемы, которые содержат большую часть моих объектов базы данных.

Я просмотрел выходные данные отладки и обнаружил, что мой объект liquibase.Liquibase и соответствующий объект liquibase.database.Database являются полными и точными с соответствующими именами databasechangelog и databasechangeloglock таблицами, указанными с текущей схемой, установленной на мое значение, но таблица журнала изменений отказывается генерировать одновременно с таблицей блокировок. К сожалению, как только я создаю таблицу databasechangelog вручную, остальные мои объекты, указанные в журнале изменений базы данных, создаются должным образом.

1 Ответ

0 голосов
/ 29 мая 2020

Я считаю, что вы не используете интеграцию SpringBoot и Liquibase так, как она должна была использоваться. Вам не нужно вызывать Liquibase напрямую. Фактически, это может быть причиной того, что создание таблицы databasechangelog не создается. Если вы настраиваете свое приложение:

  • убедитесь, что вы заполнили свой application.properties URL-адресом JDB C и указателем на журнал изменений
  • при вызове Springboot: запустите процесс автоматически увидит, что у вас есть база данных и журнал изменений, и перед запуском запустит миграцию.
  • Если вы не хотите, чтобы миграция базы данных выполнялась при запуске, а вместо этого вручную, я бы использовал Liquibase CLI в конвейере CICD (например, сценарий конвейера jenkins groovy)

Вот хороший учебник по настройке Springboot с Liquibase: https://docs.liquibase.com/tools-integrations/springboot/using-springboot-with-maven.html

Я также играл вокруг него, чтобы выяснить, используя инициализатор SpringBoot: https://start.spring.io/, добавляя Liquibase в качестве зависимости

Надеюсь, что это поможет.

...