Имеет ли смысл моя иерархия databaseChangeLog?

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

Поэкспериментировав с Liquibase в течение некоторого времени, я придумал именно это, и я хочу посмотреть, заметит ли кто-нибудь очевидные недостатки.

Поскольку в некоторых базах данных есть сотни объектов, я разбил databaseChangeLogs по типам объектов. У меня есть основной файл databaseChangeLog, который выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
                   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
	<include file="migrations/_tables.xml" relativeToChangelogFile="true"/>
	<include file="migrations/_triggers.xml" relativeToChangelogFile="true"/>
	<include file="migrations/_views.xml" relativeToChangelogFile="true"/>
	<include file="migrations/_stored_procedures.xml" relativeToChangelogFile="true"/>
</databaseChangeLog>

Поэтому при запуске миграции она сначала вносит изменения в схему в _tables.xml, затем запускает триггеры в _triggers.xml и так далее.

_Triggers.xml databaseChangeLog выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext"
                   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd">
	<changeSet id="tr_names_delete" author="PROD-1235" runOnChange="true" > <sqlFile path="triggers/tr_names_delete.sql" relativeToChangelogFile="true" /> </changeSet>
	<changeSet id="tr_names_insert" author="PROD-1235" runOnChange="true" > <sqlFile path="triggers/tr_names_insert.sql" relativeToChangelogFile="true" /> </changeSet>
	<changeSet id="tr_names_update" author="PROD-1235" runOnChange="true" > <sqlFile path="triggers/tr_names_update.sql" relativeToChangelogFile="true" /> </changeSet>
</databaseChangeLog>

У меня есть один набор изменений для каждого объекта. Чтобы я мог отслеживать изменения с течением времени в таблице DATABASECHANGELOG, я использую имя объекта в качестве идентификатора набора изменений и нашу проблему JIRA в качестве автора. Таким образом, ID будет оставаться неизменным с течением времени, но разработчики будут обновлять автора каждый раз, когда они изменяют объект. DatabaseChangeLogs для хранимых процедур, представлений и т. Д., Которые могут быть обновлены и повторно запускаться с течением времени, следуют этой же форме.

Кто-нибудь видит проблемы с таким подходом?

Спасибо за ваше время!


liquibase
person user3570706    schedule 20.03.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

  • Добавьте logicalFilePath в свои журналы изменений, чтобы иметь тот же путь в журнале изменений базы данных, если вы выполняете журналы изменений с разными путями к классам
  • Я бы не стал использовать runAllways=true для процедур. Представьте себе ситуацию, когда вы хотите вернуться к предыдущей версии. Лучше (imho) добавить только журнал изменений и использовать rollback, указывающий на предыдущую версию.
  • Иногда у вас могут быть зависимости между типами (просмотр в триггере, функция в процедуре, ...). Для этого порядок, в котором вы указали выполнение в своем основном журнале изменений, не будет работать. Но можно добавить эти изменения в отдельный журнал изменений (например, uncategorized-changes.xml).
  • если вы хотите поддерживать несколько типов баз данных, будьте готовы к тому, что вам потребуется некоторая конфигурация для некоторых функций (например, sysdate vs now() vs _7 _...). Для этого подготовьте файл, в котором вы определяете эту конфигурацию как свойства, а затем включите этот файл в свой основной журнал изменений.

В остальном ваши журналы изменений выглядят нормально.

person bilak    schedule 25.03.2019