Имеет ли смысл моя иерархия databaseChangeLog? - PullRequest
Новая
       10

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

0 голосов
/ 20 марта 2019

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

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

Поскольку в некоторых базах данных есть сотни объектов, я разбил 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 в качестве автора. Таким образом, идентификатор останется неизменным со временем, но разработчики будут обновлять автора каждый раз, когда они меняют объект. DatabaseChangeLogs для хранимых процедур, представлений и т. Д., Которые можно обновлять и повторно запускать с течением времени, следуют этой же форме.

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

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

1 Ответ

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

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

...