Shtock>> Как пример liquibase.

грустный примерПочему?

Rudyshin SergeyИз-за этих ID, когда несколько разработчиков работают на разных ветках, приходится выдумывать правила, чтобы избегать конфликтов при мерджах.В любой более-менее адекватной команде разработки всегда существуют определенные правила и стандарты, в том числе и правила наименования.

Rudyshin SergeyИ самое главное зачем вообще нужны эти идентификаторы?Этот вопрос скорее всего означает то, что вы еще не пробовали использовать этот инструмент. Считайте, что каждый changeset - это некоторое атомарное изменение БД, т.е. транзакция. ID changeset-а необходим этом для того, чтобы отслеживать, накатывался ли он на данную БД или нет (+ привязка некоторых доп параметров, типа даты (последнего) выполнения). Для каждого примененного changeset-а в БД хранится его md5 для отслеживания того, не изменился ли changeset при следующем накате.

Rudyshin SergeyЗачем нужно помещать автора в теги, если автор итак уже есть в системе контроля версий?
Хотите остаться анонимным - никто не заставляет писать реально существующую где-либо учетную запись - пишите что-нибудь типа anonymous или defaultuser. А так этот атрибут, например, позволяет одним запросом получить список changeset-ов, созданных тем или иным юзверем, при условии, что они были применены к БД.

Rudyshin SergeyВозможность пропускать скрипты, которые были уже применеы к базе - это достатчно сомнительное удовольствие.
Эта возможность точно не для боевой базы. Так как сложно себе представить, что на базу накатывают версию и не зают, что накатывают, а тул сам пропускает некие скрипты. Опять налицо непонимание. Распишу подробнее. По умолчанию changeset накатывается на БД один раз (для удобства отнесем такие к первому типу). Но можно изменить это поведение, выставив например свойство runAlways=true (пусть это будет второй тип) или runOnChange=true (а это третий).
Вот пример, как этим можно пользоваться:

Необходимо накатить изменение, а именно - добавить поле в таблицу - для этого однозначно нужно использовать changeset первого типа с SQL alter table ...
Этот changeset выполнится однократно первый раз и будет скипаться при последующих накатах патча на эту БД.

Далее, необходимо изменить логику работу ХП с изменяемой нами таблицей (перенакатить измененный код) - тут можно использовать changeset-ы либо второго, либо третьего типа. При выставленном свойстве runOnChange=true он всегда выполнится первый раз и все последующие разы, если его текст (код ХП) изменился. При выставленном свойстве runAlways=true changeset будет выполняться при каждом накате вне зависимости от того, были ли в нем какие-либо изменения.


Rudyshin SergeyПричем такой подход заставляет передавать каждый раз все скрипты за всю историю существования базы.
Подразумевает, но не обязывает. Вы всегда можете начать патчить БД c помощью liquibase не с начального состояния, но для этого нужно будет выполнить разовую синхронизацию метаданных на prod, test и dev-окружениях.

Rudyshin SergeyLiquibase attempts to execute each changeSet in a transaction that is committed at the end, or rolled back if there is an error. Some databases will auto-commit statements which interferes with this transaction setup and could lead to an unexpected database state. Therefore, it is usually best to have just one change per changeSet unless there is a group of non-auto-committing changes that you want applied as a transaction such as inserting data.
Весь этот абзац про то, что нужно как-то группировать изменения для того, чтобы избежать проблем в случае ошибок, в реальности не работает.
Если вы на боевую базу выкатываете релиз, который валится при установке, то как вы не группируйте изменения, но уже поздно.Вам никто и не говорит, что в случае ошибки этот tool сам за вас все исправит. И никакой другой инструмент не застрахует вас от ошибок.
Если в процессе наката вылезла ошибка (не хватило прав, места или что-то в этом роде), то после устранения причины проблемы вы просто повторно запускаете накат патча и он продолжит с того места, на котором он упал (при этом не забываем рекомендации по атомарности changeset-ов). Ошибки же другого рода должны отлавливаться на test-контуре, на который все изменения накатываются посредством того же самого патча.

Также есть возможность определения rollback-сценариев, но на практике мы их не используем.

Таким образом, правильно построенные патчи, при условии, что все изменения метаданных БД производятся только через пачти и никто не лазит в БД своими шаловливыми ручками с DDL-командами напрямую, дают гарантию целостности. При многократном накате патча (или патчей - логически вы можете делить их как захотите) на одну и ту же БД накатываются только те changeset-ы, необходимость которых вы явно выставите с помощью перечисленных мною выше атрибутов.

Rudyshin Sergeyмой тезис в том, что можно обойтись без идентифиторов в данном случаеЯ показал, для чего нужны идентификаторы. Если Вы по-прежнему настаиваете на том, что они не нужны, то Ваш тезис в том, что в БД не должна трекаться информация о примененных changeset-ах.

Rudyshin SergeyGit позволяет гараздо больше. На мой взгляд историю изменений лучше оставить специализированному тулу.Само собой, все changeset-ы (а соответственно и sql-скрипты) хранятся в системе контроля версий, поэтому и нет необходимости хранить все версии recreatable-объектов (view, procedure, function, package, type и т.д) в отдельных файлах. Достаточно хранить только актуальную, а все предыдущие при необходимости можно будет поднять по СКВ.

Rudyshin SergeyА теперь представьте, что процедура вызвается в нескольких changeset-ах.
Вы накатываете базу с "нуля".
В поставке последняя версия процедуры. Положим v0.42.
Вначале накатывается changeset v0.1, который вызывает версию процедуры v0.42.
Хотя когда-то changeset v0.1 вызывал процедуру версии v0.1
Это кажется неправильным.
Решением в данном случае будет хранить все версии процедуры в отдельных файлах.
Что кажется, как минимум избыточным.Не понял примера - можно понять по-разному. Соответственно не понимаю необходимости "хранить все версии процедуры в отдельных файлах".

Rudyshin SergeyНе должно быть никаких ошибок на боевой базе. Все должно быть оттестировано до.Конечно, но всегда есть человеческий фактор. Например, недооценили объем индекса на реальных данных. На тесте индекс создался, а на проде создание индекса упало, так как под него не был выделен достаточный объем.

Rudyshin SergeyБолее того, на мой взгляд скрипты не должны быть IdempotentТеперь мы должны пойти и дать по пальцам разработчику, добавившему команду "alter table move tablespace" только потому, что она, видите ли, Idempotent. И обязать всех вместо "create or replace" писать либо "create", либо "replace". И явную перекомпиляцию хранимого кода ввиду изменения зависимостей запускать запретим.
Если же хотите, чтобы каждый changeset накатывался только один раз, то пожалуйста, liquibase дает Вам возможность управлять этим свойством. Об этом я писал в своем предыдущем посте.

Rudyshin SergeyНе должны скрипты проверять, что они уже выполнились, так как это повышает вероятность ошибок.Мои скрипты ни о каких проверках и не знают, за меня это делает liquibase.

Rudyshin SergeyЭта idempotence - это по сути "exception when others then null; end;"Скорее всего Вы не поняли возможность управления свойствами runAlways и runOnChange. И вообще об отсутствии таковых. Об этом было в моем предыдущем посте. Liquibase не глотает ошибок.

Rudyshin Sergeyвот именно, еще одно бесполезная фичаТут ничего не могу сказать, так как ни разу еще не задумывался о необходимости ее использования. Допускаю, что можно найти сценарии, где это могло бы пригодиться.

Rudyshin SergeyКакие проблемы есть у Ивана и Петра, и почему они должны начать использовать liqubase?Совсем не обязательно у этих парней будут проблемы, но:
1) Данный патч не имеет возможности "повторного наката". При попытке повторного наката свалитесь на каждом "неповторяемом" statement-е. Возможность повторного наката - это не просто сферический конь в вакууме. Это не только возможность накатить версию базы с V10 на V11 (где V11 - актуальная), но и возможность накатить с помощью этого же patchset-а состояния других баз с любых других версий (с V0 на V11, с V5 на V11 и т.д.).
2) Если по какой-то причине (оборвалась связь с БД, нехватка места, выключили свет) выполнится только @JIRA-002.sql, а @JIRA-001.sql нет, то после устранения причины проблемы для продолжения наката Вам необходимо будет править файл patch.sql, комментируя вызов @JIRA-002.sql. В случае с liquibase он сам отследит выполненные changeset-ы и продолжит накат с того места, где был обрыв/падение. Никакой правки в файлах патча не требуется.
3) Если после наката патча кто-то шаловливыми ручками поправит "неповторяемый" changeset, то при попытке последующего (пере-)наката на эту же БД liquibase ругнется, и выдаст соотв-е сообщение и не начнет накат.
4) В liquibase я могу единожды выполнить настройку, которая будет запускать при каждом накате на dev и test-контурах unit-тесты, и игнорировать их запуск на проде. (Это частный пример того, что на уровне каждого changeset-а я могу выставить свойство context и управлять необходимостью его запуска на том или ином контуре).

dbpatchСадись, два.

Почему два? Ок. У тебя есть сприпт миграции, jira-002412.sql. Который делает UPDATE, используя вызов функции из специфической редакции пакета PKG_MYSUPERPUPERLOGIC. Скажем версии v223

А у тебя в дистрибутиве поставляется версия последняя пакета, допустим v301. Но скрипт миграции требует именно v223 - там допустим определенный набор параметров функции или поведение, которое сильно изменено в 301, или вообще убрано.

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

Правда ситуация становится совсем веселой, когда в v223 обнаруживается несовместимый с жизнью баг (который новую версию Oracle отправляет в ORA-0600, и который был зачинен только в 301-й).

А так да, идея что все recreatable объекты надо поставлять только последней версии - она очень привлекательна, в теории.И? Никто не мешает тебе возить с собой все необходимые версии пакетов, а также выкатывать и запускать их в нужном порядке.

dbpatchAmKadИ? Никто не мешает тебе возить с собой все необходимые версии пакетов, а также выкатывать и запускать их в нужном порядке.

ты только что утверждал, что нужно возить только самые последние версии, остальные дескать сидят в VCS.
Если ты посмотришь внимательнее, то это мой был ответ Rudyshin Sergey о том, что liquibase не берет на себя обязанность хранения всех версий объектов и вполне нормально, что этим занимается СКВ. Если в процессе наката патча необходимо использовать несколько версий - то с этим, как я уже сказал, проблем нет.

dbpatchа так - кто определит зависимости нужных версий? пакет-то может быть вовсе не standalone, и быть завязан на еще 100500 объектов из схемы, их тоже следовательно нужно возить строго нужных версий, а как это трекать, какую версию в какой момент времени применять?А это уже выходит за рамки обсуждения того, какую систему патчей использовать: liquibase или голые .sql файлы.
Liquibase определением зависимостей не занимается.

казинакэто именно конь в вакууме...
на практике этим никто не заморачивается...
чтобы повторно накатить, просто восстанавливается система с бэкапа
Восстановиться из бакапа - это значит похерить данные текущей бд. А когда эта реальна работающая БД у одного из типовых заказчиков и данные терять не хочется?

автора уж накат с любой версии на любую - это вообще нереальная фигняНу вообще-то я не говорил "на любую". Я говорил "с любой". Хотя можно заморочиться и "на любую".

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

dbpatchVCS (GIT, SVN, etc) вообще не имеет смысла в случае подхода liquebase - потому что у тебя статик файл - после релиза содержание файла уже не меняется никогда. т.е. ликвибейз берет на себя функцию VCS.Неправда.

dbpatchну и книжку прамодкумара.NoSql? Нет, не читал.

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

dbpatchно в один прекрасный день в файл миграции или зависимость на юзерский пакет вкомиттят, или под DECLARE поселят пару мегабайт глючной копипасты.Причем тут система наката патчей?

dbpatchа реентерабельность - очень прикольно звучит в случае рефакторинга вида "разделение структуры таблицы на две отдельные таблицы", или даже простейшего "партицирование таблицы".

хотя да, реентерабельно индексы строить или констрейны прикручивать, ту да, это как два пальца - пищем PL/SQL обертки и вперед.Если ты используешь "реентерабельность" при накате констрайнтов и репартиционировании - то и флаг тебе в руки.

dbpatchCREATE TABLE и CREATE INDEX, ALTER TABLE - в настоящее время делаются через специальные PL/SQL вызовы, суть которых в том, чтоб проверить - если есть индекс, и его структура как в вызове - то ничего не делать, иначе перестроить и т.п.
эти вызовы сидят в .sql файле с именем таблицы, т.е. хранится только последнее актуальное состояние таблицы (реентерабельность -же!). эти файлы тоже генерятся.
Попытался представить себе сигнатуру и тело pl/sql обертки для создания индекса. Ты проверяешь только набор и порядок полей? Уникальность/неуникальность? Или еще такие параметры tablespace, pctfree, next и т.д.?

А при добавлении поля. Проверяешь размерность, null/not null, lob store as, storage in row ... и т.д.?

Или еще лучше - добавление check-constraint-а? Проверяешь там текст?

dbpatchпараметры аж три штуки

имя таблицы,
имя индекса
column expression (там могут быть FBI, DESC и прочее).

уникальность не уникальность - это имя процедуры - .idx() или .uk(), .pk()

тонкости вида чем отличается UNIQUE INDEX от UNIQUE CONSTRAINT в рамках проекта задавили, чтоб не смущать сильно сумлевающихся - всем ходить в констрейн.

локальность или не локальность индекса определяется автоматом из набора колонок.

глобально партицированные индексы ни разу не понадобились, было решено что это все от лукавого.

параметры сториджа берутся по дефолту от тейблспейса, а сам тейблспейс от юзера.
практически никому не нужны эти тонкие материи, а кому сильно надо - тот сам потом руками сделает MOVE/REBUILD, как считает нужным.

единственное место, где есть деление тейблспейсов - это партицирование по периодам (годам), с целью пометки оных тейблспейсов как R/O.

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


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

какое-то время с этим мучались, но недостатки превысили бенефиты - при ресторе ребилд
индексов занял неприемлимое по SLA время, а пару раз вообще не прошел, потому что TEMP
не хватило, потому вкинувшего идею хранить индексы отдельно и не бекапить/ресторить - публично перед строем сильно поругали.

на этом эпопея отдельного тейблспейса для индексов была выкинута - в современных SAN и SSD условиях это полная бессмыслица даже для перфоманса.Ну и зачем такой недовелосипед (не знаю как назвать по-другому) с попыткой учесть множество ньюансов?

dbpatchон с любой VCS просто идеологически несовместим, ибо перпендикулярен ей, реализуя собственное понимание версий исходного кода: вместо package.sql ревизий 1, 322, 2251 он предлагает иметь sql000001.sql, sql000322.sql и sql002251.sql - и никакой тебе
черепашки, прыгай сам по этим файлам как хочешь, пытаясь выяснить, кто, почему и когда изменил/внес вот эту строку.

неужели это не очевидно?Ты не прав. Кто внушил тебе такой бред?

dbpatchAmKadНу и зачем такой недовелосипед (не знаю как назвать по-другому) с попыткой учесть множество ньюансов?понятное дело, чтоб вносить сумятицу и непонимание всякие в умы читателей по диагонали, зачем-же еще?На практике так ведь и получается.

dbpatchну и в чем именно я не прав? попробуй развернуть свою ээээ.... мысль, а то все телепаты ушли в отпуск, и догадаться что ты там подразумеваешь в виде отличий "такой бред" от "не такой бред", "бред, но не такой" никак не есть возможно.Ты говоришь, что liquibase несовместим с VCS и вместо package.sql ревизий 1, 322, 2251 он предлагает иметь sql000001.sql, sql000322.sql и sql002251.sql. Я говорю тебе, что ты не прав. Какие тут еще нужны пояснения?

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

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

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

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