dbpatchкак именно он предлагает хранить версии пакетов, просветишь нас тут всех, нет? с ссылкой на документацию оного, мне аж интересно стало.Давай сначала определимся, какой сценарий использования версий пакетов мы обсуждаем:
1) История версий нужна для отслеживания изменений (функционал VCS, например для просмотра diff).
2) В процессе наката требуется скомпилить и запустить несколько разных версий одного пакета.

Ну или могу сформулировать вопрос по-другому: в рассаматриваемом кейсе тебе реально нужно компилить и запускать несколько версий одного пакета, либо достаточно работать с последней версией пакета, но иметь историю его изменений в VCS?

dbpatchдаже не пытайся подвести меня под AlwaysRun и хранить пакет всегда в одном файле.Ну вот, а делал вид, что не понимаешь.

dbpatchчто я не хочу каждый раз накатывать over 9000 пакетовТолько сейчас все еще делаешь вид, как будто не знаешь про свойство runOnChange.

dbpatchliquebaseСпециально коверкаешь?

dbpatchна этом закончим?Да, пожалуй хватит.

Rudyshin Sergeyсогласен, что процедуры и подобные объекты, можно делать в виде идемпотентных скриптов, но только при условии, что каждый храниться в "нормальном" файле
и конфликты мерджа решаются через СКВ
если же помещать идемпотентные скрипты, в changeset'ы, то можно потерять изменения
пример, в котором процедура из JIRA-002 будет перетерта версией из JIRA-001


Камрад, ну не хочешь понять ты как работать с liquibase. Сhangeset-ы умеют дружить с файлами. Сhangeset - это логический объект, а файл - физический. У меня весь хранимый код хранится по файлам - отдельный .sql-файл для каждого объекта (исключения пакеты: там один файл на спеку, второй - на тело), да и вообще для каждого типа объектов - свой каталог. Это что касается физики хранения. А теперь на каждый из этих файлов натравлено по changeset-у (с выставленным либо runAlways или runOnChange). То есть при накате changeset выполняет (pl/)sql-код из файла, на который ссылается. Это что касается логики вызова.

При необходимости изменить код какого-либо объекта меняется содержимое соответствующего файла (а не добавляются новые). Это значит, что не будет описанного тобой сценария с перезатиранием объекта, а всю историю изменений объекта ты всегда можешь увидеть по СКВ.

Если же при накате тебе нужно управлять несколькими версиями объекта (пишу об этом уже N-ый раз), то тут нужно будет создать несколько файлов (и желательно для каждого отдельный changeset) - для каждой необходимой версии. Ну и описать логику управления этими версиями - а эта задача возникает вне зависимости того, каким средством ты накатываешь.

Rudyshin Sergey2) могла бы быть проблема с потерей изменений
например
JIRA-002.sql изменил состав столбцов индекса I1
JIRA-001.sql изменил уникальность I1
после выполнения patch.sql изменения JIRA-002.sql потеряныЭта проблема вне контекста выбора системы патчей. На наших проектах мы всегда выбираем ответственного за модель данных и все изменения ее структуры идут через него. А также стараемся избегать ситуаций, когда двое и более разработчиков одновременно работают над одним и тем же объектом.
Все остальные аргументы про слияние веток игнорирую - они вне контекста выбора системы патчей.

Rudyshin Sergeyв случае же оформления через changeset'ы, пришлось бы продублировать все команды по созданию таблицы, индексов и т.п.Повторяю, changeset - логический объект, файл - физический. Связь можно выстраивать любую. Скрипт генерации таблицы (или даже всей схемы целиком) можно бить на .sql-файлы как угодно. И конечно же можно вызывать один и тот же .sql-файл в разных changeset-ах.
Нет такой проблемы, все дело в непонимании принципа работы liquibase.

Rudyshin Sergeyучитывая, что на мой взгляд эти проблемы не решаются существующим тулами, то
сделал скрипт (150 строк на bash), который позволяет формировать патчи в двух форматах с учетом зависимостей между скриптами
https://github.com/SergeyRudyshin/gtbuild

сделал шаблон для использования этого скрипта в применении к бд Оракл
https://github.com/SergeyRudyshin/gtbuild_ora_template

и сделал пример, в котором можно в виртуальной машине посмотреть как оно все вместе работает в бд Оракл
https://github.com/SergeyRudyshin/gtbuild_ora_walkthrough

если кого-то заинтересует, буду рад ответить на вопросыИзвини, но мне это пока неинтересно. Ты и liquibase забраковал, до конца с ним не разобравшись, а полез изобретать собственный велосипед.

спросим девчушкуAmKadИзвини, но мне это пока неинтересно. Ты и liquibase забраковал, до конца с ним не разобравшись, а полез изобретать собственный велосипед.а с чего ты решил(а) что тебя кто-то собрался заинтересовывать?Можешь выкинуть первое предложение, основной посыл - во втором.

Rudyshin Sergeyскорее в непонимании, зачем для того, чтобы иметь таблицу DATABASECHANGELOG, тянуть в свой проект зависимость в 100 тыс строк!Управление таблицей DATABASECHANGELOG - это все, что ты смог найти?

Rudyshin SergeyПравильным, как раз скорее является подход, которого Оракл придерживается с начала времен, и я сильно сомневаюсь, что они используют XDF или Liquibase
как пример смотрю на файл
@?/rdbms/admin/catalog.sql
и его зависимости
По истории изменений видно, что файл был создан почти 30 лет назад и до сих пор меняется

если смотреть на сами скрипты, то видно, что они меняются вручную, а не генерируются (по крайней мере с первого взгляда).И у оракла бывают проблемы. На днях ставил Oracle 11.2 XE на свою виндовую локальную тачку. По завершению инсталлер говорит что все ОК - а на деле базы-то и нет. Решал по аналогии 14769174 . Я уж не говорю про проблемы при обращении к v$-вьюхам, например к v$session.