Использование Liquibase без головной боли. 10 советов из опыта реальной разработки

[mgramin]

Спасибо, хорошая статья. За пункт №8 голосую дополнительно «за».

ПС
ИМХО немного картинка смутила, т.к. часто используется в такой тематике. Сразу возникла мысль: «а не старая ли это статья?». Но прочев несколько первых предложений все понял.

[Snowindy]

Эти практики теперь можно просто показывать новым членам команды (что я и делаю), и с ходу экономить человекомесяц. Оцениваю из предыдущего опыта.

КДПВ и правда из популярных. Поищу позабористее.

[Snowindy]

Эти практики теперь можно просто показывать новым членам команды (что я и делаю), и с ходу экономить человекомесяц. Оцениваю из предыдущего опыта.

КДПВ и правда из популярных. Поищу позабористее.

[intr13]

За пост плюс, за содержание немного поворчу.

Итак:
1. Порядок в именовании файлов с ченджсетами это очень хорошо, как в прочем любой порядок. Возможно в имени ченджсета стоит отражать тип БД для которого он писан.
2. Ролбеки для ченджсетов это полезно и клево, но не стоит забывать, что надо вручную тестировать выполнения ченджсета и его откат, это обязательно!
3. В целом маленькие ченджсеты это опять про порядок в их структуре. Но есть нюансы, о них ниже.
4. Вам действительно не жаль своего времени для каждой сущности писать ченджсет? Я вам не завидую!
5. Я предпочитаю помещать ченджсеты в класспатх, и брать их относительно корня класспатх. Тога мы перестаем зависеть от операционных систем и других странностей.
6. Менять прошлое не всегда хорошая идея. В большинстве случаев надо делать отдельный ченджсет. Но тут не все так просто.
7. Согласен хранить данные в ченджсетах не очень разумная идея. Они приводят к увеличению объема ченджсетов, ну и не стоит забывать что миграции ведь для них тоже придется писать.
8. Пункт тоже логичен. Никому верить нельзя.
9. Я бы дополнил пункт, и сказал что XML ченджсеты зло, возможно хуже чем DSL. И SQL тут самое то. Удобно, быстро, прозрачно.
10. Опыт конечно хорошо, но вы бы видели исходный код liquibase. Например логер туда впилить весело :)

И в дополнении:
1. Может быть xml описание зло? Вас действительно не напрягает это писать и поддерживать? Просто я сторонник обычного нативного sql.
2. Иногда полезно делать ченджсет со всей структурой БД, куча маленьких на новой БД применяется не быстро порой. И опять я намекаю на sql ченджсеты тут.
3. Чем больше размер sql ченджсета, тем дольше считается контрольная сумма. Это еще одна из причин почему хранить данные в ченджсетах зло. Помню мегабайт текста обрабатывался за секунд 20.
4. Есть аналоги, и надо думать и пробовать что лучше. Например flyway — flywaydb.org/ (там есть таблица сравнения на подумать).

[Snowindy]

4. А как это делаете вы?
5. У меня они там же — изменения накатаваются при старте приложения. Конечно, это спорно (что, если прав нет у пользователя? Что, если надо вручную что-то накатить?). Вообще вся идея хранения пути к файлу и завязке на него в ликвибейс кажется мне непродуманной, ведь уже есть чексам…

Дополнения:
1. Нативный SQL конечно неплохо, но Liquibase берет на себя многие вопросы синтаксиса. Я говорю «создай индекс», а уж как он будет создаваться для конкретной базы — не мое дело (если все корректно создалось).
таким образом, я пишу генерализированный код, а если надо, добавляют хаков для конкретной базы, через прекондишны.
2. В бест практисас об этом сказано, что, мол, ребята, если у вас 20 версия приложения, и насчет отката до 18 версии речь уже не пойдет — сливайте все чейнджсеты, которые были до 18 версии в один большой init-SQL, и не будете долго ждать. Таких ухищрений, к счастью, я пока не делал.
4. Вы пробовали? Что лучше?

[intr13]

4. Делаю кошерный работающий скрипт и использую БД postgresql где есть транзакции в DDL — wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis
5. Согласен идея с путями не очень, я бы предпочел внутренние идентификаторы ченджсетов. А чексуммы это отдельный ад, нафиг их.

Дополнения:
1. Вы до сих пор верите в волшебные свойства библиотек? У вас всегда работает правильно конвертация xml в sql скрипт? Вам не надо на горячую писать упдейты, а потом вписывать их в ченджсеты? Опять я вам завидую :)
4. Я так и не дошел реального использования флайдб. Вроде бы у них роллбеков не было, и это немного печалило. Хотя есть надежда что там код и реализация, не такое гавно как в ликвидбейзе.

[Snowindy]

--комментарий удален---

[roman_kashitsyn]

По поводу пункта 9 — мне лично сильно не хватало макросов. Например, у нас была практика забивать словари через csv-файлы. Очень хотелось макрос, который принимал бы имя таблицы и имя файла, чтобы раз за разом не копипастить громоздкие конструкции.

[vrafael]

Использую в своем проекте для MSSQL форматированные sql-файлы, по мне так очень удобно!
1. logicalFilePath:path-independent решает вопрос с перенакатом при разных расположений из п.5
2. splitStatements:true endDelimiter:GO решает вопрос с поддержкой инструкции GO

Пример файла миграции

\migrations\20171207_WL-759_AutoLock\02_comon.Setting_Data.sql

--liquibase formatted sql
--changeset rvaliullin:20171207_WL-759_AutoLock_02_MergeTable_CommonSettings logicalFilePath:path-independent splitStatements:true endDelimiter:GO stripComments:false context:data
MERGE common.Setting as [target]
USING
    (
        VALUES
            (N'ComplaintCountForAutoLock', N'10')
    ) as [source] (SettingCode, SettingValue)
        ON [source].SettingCode = [target].SettingCode
WHEN MATCHED THEN
    UPDATE
    SET
        SettingValue = [source].SettingValue
WHEN NOT MATCHED BY TARGET THEN
    INSERT
    (
        SettingCode,
        SettingValue
    )
    VALUES
    (
        [source].SettingCode,
        [source].SettingValue
    );
GO