Автоматический откат Liquibase

Я работаю над веткой, и, например, мне нужно удалить столбец в таблице X, я добавляю изменение, и оно подходит для этой конкретной ветки, затем я переключаюсь на другую ветку, для которой все еще требуется этот столбец, и это изменение необходимо откатить . В БД много изменений, например, от ветки к ветке.

Я добавляю новый XML-журнал изменений для каждой ветки и включаю его в основной XML-журнал изменений. Очевидно, когда я переключаюсь на другую ветку, changlog xml для предыдущей ветки больше не находится в рабочей области, и Liquibase не сохраняет фактический набор изменений в базе данных, только его имя и время его применения, поэтому он не сможет откатить изменения автоматически.

Я использую сервлет Liquibase для внесения изменений при запуске моего приложения.

Эксперты Liquibase, есть ли уже реализованное простое решение этой проблемы? Спасибо!


java liquibase
person user979051    schedule 20.04.2012    source источник
comment
У вас одна база данных и много филиалов? Или это временная база данных, новая при каждом запуске теста?   -  person yegor256    schedule 20.04.2012
comment
Думаю, вам понадобится а) одна БД для каждой ветки б) по одному журналу изменений для каждой ветки. Ведение единого журнала изменений для нескольких веток оказалось подверженным ошибкам   -  person a_horse_with_no_name    schedule 20.04.2012
comment
У меня есть журнал изменений для каждой ветки и только один экземпляр базы данных для всех, мне не нужно несколько баз данных, так как я единственный разработчик.   -  person user979051    schedule 20.04.2012
comment
@ user979051: если у вас несколько веток, вам нужно несколько баз данных. Все остальное доставит вам неприятности (и поэтому вы разместили вопрос)   -  person a_horse_with_no_name    schedule 21.04.2012

Ответы (1)


arrow_upward
3
arrow_downward

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

Liquibase предназначена для использования наборов изменений на основе файлов в качестве основной записи для изменения базы данных. Специальная таблица DATABASECHANGELOG предназначена для отслеживания того, какие наборы изменений были применены к экземпляру базы данных. Переключение между ветвями вызывает путаницу множеством непредсказуемых причин, например:

  • Отсутствующие наборы изменений
  • Наборы изменений, содержимое которых изменилось (приводит к ошибкам контрольной суммы).
  • ...

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

liquibase dropAll
liquibase update

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

Если вас беспокоит потеря данных, используйте контексты для управления тестовыми данными.

Обновлять

Если вы используете Maven, эту операцию "повторной синхронизации" можно вызвать из Maven следующим образом:

mvn -Presync compile

Этот профиль настроен в вашем POM следующим образом:

    <profile>
        <id>resync</id>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.liquibase</groupId>
                    <artifactId>liquibase-maven-plugin</artifactId>
                    <version>${liquibase.plugin.version}</version>
                    <executions>
                        <execution>
                            <phase>process-resources</phase>
                            <configuration>
                                <url>${liquibase.url}</url>
                                <driver>${liquibase.driver}</driver>
                                <username>${liquibase.username}</username>
                                <password>${liquibase.password}</password>
                                <changeLogFile>${liquibase.changeLogFile}</changeLogFile>
                                <promptOnNonLocalDatabase>false</promptOnNonLocalDatabase>
                            </configuration>
                            <goals>
                                <goal>dropAll</goal>
                                <goal>update</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile>
person Mark O'Connor    schedule 21.04.2012