Комментарии 9
Спасибо, хорошая статья. За пункт №8 голосую дополнительно «за».
ПС
ИМХО немного картинка смутила, т.к. часто используется в такой тематике. Сразу возникла мысль: «а не старая ли это статья?». Но прочев несколько первых предложений все понял.
ПС
ИМХО немного картинка смутила, т.к. часто используется в такой тематике. Сразу возникла мысль: «а не старая ли это статья?». Но прочев несколько первых предложений все понял.
Эти практики теперь можно просто показывать новым членам команды (что я и делаю), и с ходу экономить человекомесяц. Оцениваю из предыдущего опыта.
КДПВ и правда из популярных. Поищу позабористее.
КДПВ и правда из популярных. Поищу позабористее.
За пост плюс, за содержание немного поворчу.
Итак:
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/ (там есть таблица сравнения на подумать).
Итак:
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/ (там есть таблица сравнения на подумать).
4. А как это делаете вы?
5. У меня они там же — изменения накатаваются при старте приложения. Конечно, это спорно (что, если прав нет у пользователя? Что, если надо вручную что-то накатить?). Вообще вся идея хранения пути к файлу и завязке на него в ликвибейс кажется мне непродуманной, ведь уже есть чексам…
Дополнения:
1. Нативный SQL конечно неплохо, но Liquibase берет на себя многие вопросы синтаксиса. Я говорю «создай индекс», а уж как он будет создаваться для конкретной базы — не мое дело (если все корректно создалось).
таким образом, я пишу генерализированный код, а если надо, добавляют хаков для конкретной базы, через прекондишны.
2. В бест практисас об этом сказано, что, мол, ребята, если у вас 20 версия приложения, и насчет отката до 18 версии речь уже не пойдет — сливайте все чейнджсеты, которые были до 18 версии в один большой init-SQL, и не будете долго ждать. Таких ухищрений, к счастью, я пока не делал.
4. Вы пробовали? Что лучше?
5. У меня они там же — изменения накатаваются при старте приложения. Конечно, это спорно (что, если прав нет у пользователя? Что, если надо вручную что-то накатить?). Вообще вся идея хранения пути к файлу и завязке на него в ликвибейс кажется мне непродуманной, ведь уже есть чексам…
Дополнения:
1. Нативный SQL конечно неплохо, но Liquibase берет на себя многие вопросы синтаксиса. Я говорю «создай индекс», а уж как он будет создаваться для конкретной базы — не мое дело (если все корректно создалось).
таким образом, я пишу генерализированный код, а если надо, добавляют хаков для конкретной базы, через прекондишны.
2. В бест практисас об этом сказано, что, мол, ребята, если у вас 20 версия приложения, и насчет отката до 18 версии речь уже не пойдет — сливайте все чейнджсеты, которые были до 18 версии в один большой init-SQL, и не будете долго ждать. Таких ухищрений, к счастью, я пока не делал.
4. Вы пробовали? Что лучше?
4. Делаю кошерный работающий скрипт и использую БД postgresql где есть транзакции в DDL — wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis
5. Согласен идея с путями не очень, я бы предпочел внутренние идентификаторы ченджсетов. А чексуммы это отдельный ад, нафиг их.
Дополнения:
1. Вы до сих пор верите в волшебные свойства библиотек? У вас всегда работает правильно конвертация xml в sql скрипт? Вам не надо на горячую писать упдейты, а потом вписывать их в ченджсеты? Опять я вам завидую :)
4. Я так и не дошел реального использования флайдб. Вроде бы у них роллбеков не было, и это немного печалило. Хотя есть надежда что там код и реализация, не такое гавно как в ликвидбейзе.
5. Согласен идея с путями не очень, я бы предпочел внутренние идентификаторы ченджсетов. А чексуммы это отдельный ад, нафиг их.
Дополнения:
1. Вы до сих пор верите в волшебные свойства библиотек? У вас всегда работает правильно конвертация xml в sql скрипт? Вам не надо на горячую писать упдейты, а потом вписывать их в ченджсеты? Опять я вам завидую :)
4. Я так и не дошел реального использования флайдб. Вроде бы у них роллбеков не было, и это немного печалило. Хотя есть надежда что там код и реализация, не такое гавно как в ликвидбейзе.
--комментарий удален---
По поводу пункта 9 — мне лично сильно не хватало макросов. Например, у нас была практика забивать словари через csv-файлы. Очень хотелось макрос, который принимал бы имя таблицы и имя файла, чтобы раз за разом не копипастить громоздкие конструкции.
Использую в своем проекте для MSSQL форматированные sql-файлы, по мне так очень удобно!
1. logicalFilePath:path-independent решает вопрос с перенакатом при разных расположений из п.5
2. splitStatements:true endDelimiter:GO решает вопрос с поддержкой инструкции GO
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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование Liquibase без головной боли. 10 советов из опыта реальной разработки