Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 СУБД. История изменений  [new]
Andrey3k
Member

Откуда:
Сообщений: 82
Разрабатываем проект с базой данных Oracle.

Как можно хранить историю изменений базы данных ? Например изменили структуру таблиц и процедуры, нужно это дело сохранить в системе контроля версий.

Предложите варианты и идеи.
11 июл 16, 16:04    [19395808]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 43932

Andrey3k
Предложите варианты и идеи.

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

Posted via ActualForum NNTP Server 1.5

11 июл 16, 16:13    [19395865]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
ora601
Member

Откуда:
Сообщений: 749
Andrey3k
Разрабатываем проект с базой данных Oracle.

Как можно хранить историю изменений базы данных ? Например изменили структуру таблиц и процедуры, нужно это дело сохранить в системе контроля версий.

Предложите варианты и идеи.


Гуглите по кейворду версионирование бд. Как пример liquibase.
11 июл 16, 16:24    [19395940]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
andreymx
Member

Откуда: Запорожье
Сообщений: 43604
ora601
Гуглите по кейворду версионирование бд. Как пример liquibase.
необычная фамилия
+
11 июл 16, 16:38    [19396000]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
SAS2014
Member

Откуда: Сталинград
Сообщений: 1926
Andrey3k
Разрабатываем проект с базой данных Oracle.

Как можно хранить историю изменений базы данных ? Например изменили структуру таблиц и процедуры, нужно это дело сохранить в системе контроля версий.

Предложите варианты и идеи.


По пробовать запустить аудит, создается таблица в базе (так же будет занимать место в бд) с этой табличкой можно будет делать все что хочешь, например отчет в виде html
12 июл 16, 07:15    [19397716]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
Shtock
Member

Откуда: СПб
Сообщений: 2966
>> Как пример liquibase.

грустный пример
12 июл 16, 19:03    [19401452]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
Rudyshin Sergey
Member

Откуда: Владивосток
Сообщений: 51
Всем привет!

давно хотелось сделать нечто, что позволяло бы удобно работать с историей изменений объектов бд.
Разные Flyway, Liquibase не устраивали по разным причинам
Например, хранение версий в названиях файлов, приводит к конфликтам при слиянии веток. Не поддерживается нотация sqlplus.

если интересно, то интерактиный пример можно найти здесь
8 янв 17, 22:14    [20083089]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
Алекссс
Member

Откуда:
Сообщений: 1555
не каждая компиляция процедуры нужна для фиксации ее версии, потому аудит отдельно, версии отдельно
9 янв 17, 14:43    [20084846]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
AmKad
Member

Откуда:
Сообщений: 4689
Shtock
>> Как пример liquibase.

грустный пример
Почему?
9 янв 17, 16:15    [20085308]     Ответить | Цитировать Сообщить модератору
 Re: СУБД. История изменений  [new]
Rudyshin Sergey
Member

Откуда: Владивосток
Сообщений: 51
>> Почему?

ну вот сморю на главную страницу liquibase и читаю первые два пункта
  • Supports code branching and merging
  • Supports multiple developers

    далее у них же читаю http://www.liquibase.org/documentation/changeset.html
    Each changeSet tag is uniquely identified by the combination of the “id” tag, the “author” tag, and the changelog file classpath name. The id tag is only used as an identifier, it does not direct the order that changes are run and does not even have to be an integer. If you do not know or do not wish to save the actual author, simply use a placeholder value such as “UNKNOWN”.

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

    Зачем нужно помещать автора в теги, если автор итак уже есть в системе контроля версий?
    As Liquibase executes the databaseChangeLog, it reads the changeSets in order and, for each one, checks the “databasechangelog” table to see if the combination of id/author/filepath has been run. If it has been run, the changeSet will be skipped unless there is a true “runAlways” tag. After all the changes in the changeSet are run, Liquibase will insert a new row with the id/author/filepath along with an MD5Sum of the changeSet (see below) in the “databasechangelog”.

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

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

    Зачем это? Почему я не могу передать только изменения и номер версии к которой они применимы? Непонятно.
    Liquibase 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.

    Весь этот абзац про то, что нужно как-то группировать изменения для того, чтобы избежать проблем в случае ошибок, в реальности не работает.
    Если вы на боевую базу выкатываете релиз, который валится при установке, то как вы не группируйте изменения, но уже поздно.
  • 9 янв 17, 21:30    [20086377]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4689
    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 будет выполняться при каждом накате вне зависимости от того, были ли в нем какие-либо изменения.
    + P.S.
    Выделенное жирным - не более, чем демагогия, уж простите.


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

    Rudyshin Sergey
    Liquibase 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-ы, необходимость которых вы явно выставите с помощью перечисленных мною выше атрибутов.
    10 янв 17, 12:41    [20088443]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    Демагог
    Guest
    AmKad, sql оборачивать в xml... очень все трудно.
    Мы в один файл.sql все пишем и из него накатываем. А этот ваш ликвибейз, там ант, мавен и прочее нужно. Очень муторно.
    10 янв 17, 12:57    [20088522]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    Владимир СА
    Member

    Откуда:
    Сообщений: 7555
    Демагог
    AmKad, sql оборачивать в xml... очень все трудно.
    Мы в один файл.sql все пишем и из него накатываем. А этот ваш ликвибейз, там ант, мавен и прочее нужно. Очень муторно.
    Ликви берет и SQL
    --liquibase formatted sql
    ...
    и пошел писать changeset-ы
    

    без пролем...
    Но AmKad очень все красиво описал... респект...
    10 янв 17, 13:10    [20088601]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    Демагог
    Guest
    Владимир СА, спасибо, буду знать!
    10 янв 17, 14:00    [20088981]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    Rudyshin Sergey
    Member

    Откуда: Владивосток
    Сообщений: 51
    > В любой более-менее адекватной команде разработки всегда существуют определенные правила и стандарты, в том числе и правила наименования.

    мой тезис в том, что можно обойтись без идентифиторов в данном случае, и ни в коем случае не в том, что не должно быть вообще никаких правил

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

    Git позволяет гараздо больше. На мой взгляд историю изменений лучше оставить специализированному тулу.

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

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

    > Если в процессе наката вылезла ошибка (не хватило прав, места или что-то в этом роде), то после устранения причины проблемы вы просто повторно запускаете накат патча и он продолжит с того места

    Если в процессе наката на боевой базе возникла ошибка, то может что-то в консерватории подправить?
    Не должно быть никаких ошибок на боевой базе. Все должно быть оттестировано до.
    Более того, на мой взгляд скрипты не должны быть Idempotent.
    А наоборот должны быть https://en.wikipedia.org/wiki/Fail-fast
    Не должны скрипты проверять, что они уже выполнились, так как это повышает вероятность ошибок.
    Особенно при работе на ветках разными разработчиками.
    Эта idempotence - это по сути "exception when others then null; end;"
    "exception when then others null; end;" - тоже работает некоторое время ...

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

    вот именно, еще одно бесполезная фича

    > Таким образом, правильно построенные патчи, при условии, что все изменения метаданных БД производятся только через пачти и никто не лазит в БД своими шаловливыми ручками с DDL-командами напрямую, дают гарантию целостности

    Согласен и предлагаю рассмотреть пример, в котором не используются ни идентификаторы, ни liqubase
    но тем не менее позволяет делать все тоже самое

    Разработчик Иван на бранче JIRA-001 создал файл JIRA-001.sql и добавил его вызов в patch.sql

    JIRA-001.sql
    create table a (n number);
    
    patch.sql
    @JIRA-001.sql
    


    Разработчик Петр на бранче JIRA-002
    JIRA-002.sql
    create table b (n number);
    
    patch.sql
    @JIRA-002.sql
    


    У каждого разработчика есть образ виртуальной машины, который соответствет версии боевой базы.
    Каждый из них проверили работоспособность своих скриптов.
    Отдали руководителю на интеграцию.
    Изменения были смерджины и протестированы
    JIRA-001.sql
    create table a (n number);
    
    JIRA-002.sql
    create table b (n number);
    
    patch.sql
    @JIRA-002.sql
    @JIRA-001.sql
    


    Какие проблемы есть у Ивана и Петра, и почему они должны начать использовать liqubase?
    10 янв 17, 20:46    [20091159]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    AmKad
    Member

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

    Rudyshin Sergey
    Git позволяет гараздо больше. На мой взгляд историю изменений лучше оставить специализированному тулу.
    Само собой, все 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 и управлять необходимостью его запуска на том или ином контуре).
    11 янв 17, 13:31    [20093499]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    dbpatch
    Member

    Откуда:
    Сообщений: 1033
    Andrey3k
    Разрабатываем проект с базой данных Oracle.

    Как можно хранить историю изменений базы данных ? Например изменили структуру таблиц и процедуры, нужно это дело сохранить в системе контроля версий.

    Предложите варианты и идеи.


    ты вполне можешь генерировать структуру базы данных в текстовом виде (через DBMS_METADATA) и складировать ее в текстовые файлы, которые отправлять в SVN или GIT

    отдельно можно настроить экспорт DBA_AUDIT_STATEMENTS, в пределах объектов - там будет видно, кто "создавал" или "заменял" объект за прошлый день - эти данные можно как коммент к комитту прикреплять.

    аналогично можно выгружать в текстовый вид и данные статичных справочников


    это если в варианте постфактум.

    а так да, нужно привинтить систему контроля изменений версий "до", но нормальных решений в свободном доступе практически нет, упомянутые liquebase и подобные отражения подходов из известной книжки refactoring databases категорически не совместимы с базовой идеей VCS систем, особенно если у тебя бренчи, бекмержи и подобное.

    очень неплох Oracle ODF/XDF тулчейн из OEBS, но это для избранных, отдельно он ИМНИП не поставляется
    11 янв 17, 17:17    [20094841]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    dbpatch
    Member

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


    Садись, два.

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

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

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

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

    А так да, идея что все recreatable объекты надо поставлять только последней версии - она очень привлекательна, в теории.
    11 янв 17, 17:23    [20094872]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    казинак
    Member

    Откуда:
    Сообщений: 1018
    Andrey3k
    Разрабатываем проект с базой данных Oracle.

    Как можно хранить историю изменений базы данных ? Например изменили структуру таблиц и процедуры, нужно это дело сохранить в системе контроля версий.

    Предложите варианты и идеи.

    история изменений и так в архивлогах есть
    https://docs.oracle.com/database/121/SUTIL/GUID-E0DDC97C-7364-4BED-AF2A-E0B486F0E22F.htm
    11 янв 17, 17:52    [20094997]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4689
    dbpatch
    Садись, два.

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

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

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

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

    А так да, идея что все recreatable объекты надо поставлять только последней версии - она очень привлекательна, в теории.
    И? Никто не мешает тебе возить с собой все необходимые версии пакетов, а также выкатывать и запускать их в нужном порядке.
    11 янв 17, 17:59    [20095032]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    dbpatch
    Member

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


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

    а так - кто определит зависимости нужных версий? пакет-то может быть вовсе не standalone, и быть завязан на еще 100500 объектов из схемы, их тоже следовательно нужно возить строго нужных версий, а как это трекать, какую версию в какой момент времени применять?

    ты походу или теоретик, или просто поговорить хочешь?
    11 янв 17, 18:05    [20095053]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    казинак
    Member

    Откуда:
    Сообщений: 1018
    AmKad
    ...Возможность повторного наката - это не просто сферический конь в вакууме. Это не только возможность накатить версию базы с V10 на V11 (где V11 - актуальная), но и возможность накатить с помощью этого же patchset-а состояния других баз с любых других версий (с V0 на V11, с V5 на V11 и т.д.)....

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

    а уж накат с любой версии на любую - это вообще нереальная фигня
    тот же оракл не поддерживает прямой апгрейд скажем с 8-й версии на 11-ю

    ну т.е. можно конечно тратить время на то, чтоб пытаться делать патчи реентерабельными да еще и суперуниверсальными, типа, с любой версии на любую, но этой херней занимаются только конченные чудаки.
    11 янв 17, 18:18    [20095110]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4689
    dbpatch
    AmKad
    И? Никто не мешает тебе возить с собой все необходимые версии пакетов, а также выкатывать и запускать их в нужном порядке.


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

    dbpatch
    а так - кто определит зависимости нужных версий? пакет-то может быть вовсе не standalone, и быть завязан на еще 100500 объектов из схемы, их тоже следовательно нужно возить строго нужных версий, а как это трекать, какую версию в какой момент времени применять?
    А это уже выходит за рамки обсуждения того, какую систему патчей использовать: liquibase или голые .sql файлы.
    Liquibase определением зависимостей не занимается.
    11 янв 17, 18:18    [20095115]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    dbpatch
    Member

    Откуда:
    Сообщений: 1033
    AmKad
    dbpatch
    пропущено...


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

    Как раз наоборот - в их идеологии ты обязан вносить каждое изменение объекта в свой отдельный пронумерованный файл, и возить это потом с собой. Ну понятное дело, что если ты в течении дня сделал over 9000 изменений пакета, то тебе не нужно делать 9000 файлов, но то что ушло в деплой - уже всё, статик файл, менять нельзя, ибо зависимости.

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


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

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


    AmKad
    Liquibase определением зависимостей не занимается.

    как раз занимается, это ты просто не осилил его документацию и примеры, ну и книжку прамодкумара.

    садись два, еще раз.

    зачем лезть в спор, если матчасть не освоена?
    11 янв 17, 18:24    [20095144]     Ответить | Цитировать Сообщить модератору
     Re: СУБД. История изменений  [new]
    AmKad
    Member

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

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

    автор
    ну т.е. можно конечно тратить время на то, чтоб пытаться делать патчи реентерабельными да еще и суперуниверсальными, типа, с любой версии на любую, но этой херней занимаются только конченные чудаки.
    Представь себе, по трудоемкости и сложности это не сильно отличается от последовательного добавления sql-статементов в .sql-файлы.
    11 янв 17, 18:30    [20095165]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
    Все форумы / Oracle Ответить