Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Version Control для pl/sql  [new]
Goofy122
Member

Откуда:
Сообщений: 198
Кто знает есть ли Version Control для pl/sql типо GIT. При чтобы не обновять вручную. Если есть дайте напишите название пожалуйста
29 сен 17, 15:10    [20831968]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
капица
Guest
Goofy122
типо GIT
git
29 сен 17, 15:12    [20831974]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
Goofy122
Member

Откуда:
Сообщений: 198
капица
Goofy122
типо GIT
git


Для PL/SQL
29 сен 17, 15:17    [20831992]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
AmKad
Member

Откуда:
Сообщений: 4868
Goofy122
Version Control для pl/sql
Что значит "для pl/sql"?
Goofy122
При чтобы не обновять вручную.
Что значит "обновять вручную"?

Формализуй требования.
29 сен 17, 15:18    [20831998]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
Goofy122
Member

Откуда:
Сообщений: 198
AmKad
Goofy122
Version Control для pl/sql
Что значит "для pl/sql"?
Goofy122
При чтобы не обновять вручную.
Что значит "обновять вручную"?

Формализуй требования.



Извиняюсь за глупый вопрос , я просто ни разу не использовал. Например в GIT если создать папку и перебрасывать pl/sql файлы то есть packages. При каждом обновлении дайлов packages (Merce) в Git. Они буду именяться то есть для каждого девелопера , чтобы видели последние изменения ?
29 сен 17, 16:19    [20832195]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
dmdmdm
Member

Откуда: Нижний Новгород
Сообщений: 1041
Прекрасное владение русским языком.
Задайте себе вопрос: "какая разница, PL/SQL или в системе контроля версий или что-то еще".
29 сен 17, 16:27    [20832222]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
Кроик Семён
Member

Откуда: СПб --> Dortmund
Сообщений: 6132
Goofy122,

Вариант 1: Для ленивых
Некоторые программы умеют генерировать скрипт создания схемы / или даже всей базы и сохранять его в гигантский такой текстовый файл. Его можно сохранять в GIT. На первый взгляд круто и достаточно, но когда сущности иногда переименовываются (не только таблицы, но и процедуры), то в скрипте меняется порядок следования этих сущностей. И это затрудняет сравнение старых и новых версий. По-этому предлагаю 2-ой вариант.


Вариант 2: Мой путь

веду разработку

а) проектирование таблиц / связей / секвенций в ER/Win.
- который экспортирует скрипт создания схемы в большой текстовый файл

б) остальное в PL/SQL- Developer'e
- триггеров
- процедур и функций
- VIEW
- пакетов
- и т.д. (короче всех остальных объектов)

... и всё что попадает в БД сохраняется мной [Ctrl+S] в текстовые файлы. ВСЕГДА.


В результате имеем папку с текстовыми файлами, которые удобно сохранять в GIT'e
29 сен 17, 16:49    [20832290]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
Очевидность
Guest
Goofy122
Извиняюсь за глупый вопрос , я просто ни разу не использовал.


Не обращай внимание, тут не умеют объяснять. Сейчас я тебе объясню.

GIT можна накат и все pl/sql и розаработчеки видет тваи изменения пакет новый. А еще локально клавиатура писать править, все харашо.
29 сен 17, 16:51    [20832297]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
env
Member

Откуда: Россия, Москва
Сообщений: 5809
Goofy122,

Большинство IDE умеют интегрироваться с системой контроля версий. Но вся разработка при этом идёт через файлы - без вариантов.

Реактивный (т.е. по факту изменения) вариант уже предложили - генерить скрипт из бд.
29 сен 17, 16:57    [20832313]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
AmKad
Member

Откуда:
Сообщений: 4868
Кроик Семён,

А как накатываешь изменения на уже работающую бд?
29 сен 17, 17:04    [20832328]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
dbms_photoshop
Member

Откуда: sqlmdx.net
Сообщений: 5065
Goofy122,

Данный отвечатель делает так:
git checkout
git pull
Файл объкта в редакторе открывай, изменения делай, на диск сохраняй.
git add
git commit
git push
Если команд лайн тяжело понимай tortoise svn мочь тебе помогай данная задача выполняй,
есть интеграция в intellij и прочая IDE - тогда пыхти, код пиши, когда готово мышкой клик vcs -> commit changes IDE за тебя изменения заливай.

А можно так: потей воняй на другую система контроля переходи всё UI,
гит когда бранч для каждый девелопер и команд лайн забывай, голову не засоряй.
29 сен 17, 17:17    [20832347]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
orac_list
Member

Откуда:
Сообщений: 109
[url=]http://gitora.com[/url]
29 сен 17, 17:19    [20832349]     Ответить | Цитировать Сообщить модератору
 Re: Version Control для pl/sql  [new]
Кроик Семён
Member

Откуда: СПб --> Dortmund
Сообщений: 6132
AmKad
Кроик Семён,
А как накатываешь изменения на уже работающую бд?



  • проектирую на девелоперской базе
  • все CREATE TABLE / ALTER TABLE / INSERT / UPDATE / RENAMEs записываю в Update-скрипт
  • внизу этого скрипта еще TODO-список из указаний, какие процедуры/функции/пакеты создать. Они лежат и разрабатываются в виде отдельных файлов и не имеет смысла их полностю раскрывать в Update-скрипте
  • когда приходит час X: если оповещаю пользователей, затем подменяю EXE-файл с клиентским приложением, затем выполняю Update-скрипт со всеми TODO, затем компилирую invalid objects. Если никто не блокирует никаких таблиц, то аптейт умещается в 1-5 минут в зависимости от длины TODO-списка
  • 29 сен 17, 17:33    [20832370]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    Кроик Семён
    Member

    Откуда: СПб --> Dortmund
    Сообщений: 6132
    P.S.
    забыл самое важное сказать

    Update-скрипт накатываю в программе Keeptool HORA
    всё из-за того, что когда встречается фрагмент Update-скрипта, который вызывает ошибку, то накатывание останавливается и HORA перематывает скрипт до этого места задает вопрос, выполнять дальше или остановка.
    29 сен 17, 17:47    [20832392]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    Goofy122
    Member

    Откуда:
    Сообщений: 198
    Кроик Семён
    Goofy122,

    Вариант 1: Для ленивых
    Некоторые программы умеют генерировать скрипт создания схемы / или даже всей базы и сохранять его в гигантский такой текстовый файл. Его можно сохранять в GIT. На первый взгляд круто и достаточно, но когда сущности иногда переименовываются (не только таблицы, но и процедуры), то в скрипте меняется порядок следования этих сущностей. И это затрудняет сравнение старых и новых версий. По-этому предлагаю 2-ой вариант.


    Вариант 2: Мой путь

    веду разработку

    а) проектирование таблиц / связей / секвенций в ER/Win.
    - который экспортирует скрипт создания схемы в большой текстовый файл

    б) остальное в PL/SQL- Developer'e
    - триггеров
    - процедур и функций
    - VIEW
    - пакетов
    - и т.д. (короче всех остальных объектов)

    ... и всё что попадает в БД сохраняется мной [Ctrl+S] в текстовые файлы. ВСЕГДА.


    В результате имеем папку с текстовыми файлами, которые удобно сохранять в GIT'e



    То что нужно спасибо большое
    29 сен 17, 17:50    [20832402]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    Кроик Семён
    AmKad
    Кроик Семён,
    А как накатываешь изменения на уже работающую бд?



  • проектирую на девелоперской базе
  • все CREATE TABLE / ALTER TABLE / INSERT / UPDATE / RENAMEs записываю в Update-скрипт
  • внизу этого скрипта еще TODO-список из указаний, какие процедуры/функции/пакеты создать. Они лежат и разрабатываются в виде отдельных файлов и не имеет смысла их полностю раскрывать в Update-скрипте
  • Бывает так, что забыл добавить в update-скрипт или вызвать перекомпиляцию измененной ХП, и в результате, получил состояние прода, отличающее неполнотой по отношению к дев-у? Если да, то сколько времени уходит на то, чтобы понять, какое из изменений было пропущено?
    29 сен 17, 17:50    [20832406]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    Кроик Семён
    Member

    Откуда: СПб --> Dortmund
    Сообщений: 6132
    такое всего пару раз случалось за десять лет
    и учитывая, что у меня в основном не ХП, а пакеты с процедурами/функциями, то и неправильная версия пакета вылетает очень быстро у какого-нибудь из пользователей через пару минут после апдейта с сообщением, что обращение к несуществующей процедуре
    29 сен 17, 19:14    [20832483]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    sharkerr
    Member

    Откуда:
    Сообщений: 36
    Goofy122
    Кто знает есть ли Version Control для pl/sql типо GIT. При чтобы не обновять вручную. Если есть дайте напишите название пожалуйста


    Gitora http://www.gitora.com/
    либо liquibase http://www.liquibase.org/, но нужно допиливать плагин для Oracle (ограниченный он какой-то)
    30 сен 17, 10:32    [20833120]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    sharkerr
    либо liquibase http://www.liquibase.org/, но нужно допиливать плагин для Oracle (ограниченный он какой-то)
    А можно поподробнее?
    30 сен 17, 10:44    [20833129]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    sharkerr, orac_list
    Gitora http://www.gitora.com/
    Посмотрел презентацию и документацию, касающуюся Managed Schema. Позволю себе попридираться.

    0) Презентация содержит только примеры управление пакетами. Продемонстрирована только двусторонняя синхронизация между активной веткой репозитория и БД - только на примере пакетов, это не очень интересно. Гораздо интереснее было бы взглянуть на управление hard objects (выражение взято из их документации), как таблицы, индексы, констраинты. Идем дальше.
    1) Смотрим документацию. Из того, что я понял, на dev-схему вешается некий listener ddl-команд (вероятно ddl-триггер). И прокатив список команд (цитирую из той же доки)

    ALTER TABLE COUNTRIES MODIFY (COUNTRY_NAME VARCHAR2 (200))
     
    ALTER TABLE EMPLOYEES ADD (MIDDLE_NAME VARCHAR2 (25))
     
    ALTER TABLE COUNTRIES ADD (CURRENCY_NAME VARCHAR2 (200))
    

    в результате на каком-то из последующих этапов (видимо, при коммите) получаем пакет наката на последующие контура:

    + Пакет для наката
    CREATE OR REPLACE
    PACKAGE BODY gitora_model1 IS
     
    function doModel return clob is
      v_log_cl clob;
      v_ddl_cl clob;
      v_cursor_int integer;
      return_value integer;
      procedure log(in_text_cl clob) is
      begin
        v_log_cl:=v_log_cl||in_text_cl||chr(10);
      end;
    begin
      /*GITORA GENERATED COMMENT. DO NOT EDIT OR REMOVE. ONLY WRITE CODE UNDER THIS LINE.*/
      null;
       
      /*SCRIPT FOR HR.COUNTRIES by user:admin */
      begin
        v_ddl_cl:='ALTER TABLE COUNTRIES 
       MODIFY (
        COUNTRY_NAME VARCHAR2 (200)
       
       )
      ';
        log(v_ddl_cl);
        execute immediate v_ddl_cl;
        log('DDL executed successfully.');
      exception
        when others then
          log('ERROR:'||' '||SQLErrm||' '||dbms_utility.format_error_backtrace);
      end;
       
      /*SCRIPT FOR HR.EMPLOYEES by user:admin */
      begin
        v_ddl_cl:='ALTER TABLE EMPLOYEES 
       ADD (
        MIDDLE_NAME VARCHAR2 (25)
       )
      ';
        log(v_ddl_cl);
        execute immediate v_ddl_cl;
        log('DDL executed successfully.');
      exception
        when others then
          log('ERROR:'||' '||SQLErrm||' '||dbms_utility.format_error_backtrace);
      end;
       
      /*SCRIPT FOR HR.COUNTRIES by user:admin */
      begin
        v_ddl_cl:='ALTER TABLE COUNTRIES 
       ADD (
        CURRENCY_NAME VARCHAR2 (200)
       )
      ';
        log(v_ddl_cl);
        execute immediate v_ddl_cl;
        log('DDL executed successfully.');
      exception
        when others then
          log('ERROR:'||' '||SQLErrm||' '||dbms_utility.format_error_backtrace);
      end;
      /*GITORA GENERATED COMMENT. DO NOT EDIT OR REMOVE. ONLY WRITE CODE ABOVE THIS LINE.*/
      return v_log_cl;
    end;
    end;
    
    Из того, что мне сразу бросилось в глаза - никакого логирования в перманентные таблицы об ходе выполнения. Собственно, читаем доку дальше.

    http://blog.gitora.com/tag/documentation/
    Errors during its execution does not prevent the doModel function from executing remaning DDL statements.
    Да, по коду это видно. Сомнительная фича.

    http://blog.gitora.com/tag/documentation/
    The function captures these errors and returns them as a CLOB value.
    Та-а-к. Запустил я процедуру DoModel. А за месячный релиз у меня там столько alter-ов собралось - по пальцам рук и ног десяти сотрудников не сосчитаешь. И тут в какой-то момент у меня теряется связь с сервером (причину выберем самую абсурдную - я ногой случайно пилот выключил) - не получил я ответный clob в общем. Включаю снова комп, переподключаюсь к БД. А как теперь понять, какие alter-ы прошли, а какие упали? У тут я понимаю, что в обещанный мною моему начальнику получасовой простой системы я не укладываюсь, а тот, в свою очередь, премию урежет, и пиво лишний раз на радостях попить не сходишь. Эх нога, нога, лучше б я тебя к стулу привязал.

    Ну да ладно, допустим, ногой я не дрыгал и ответный clob все-таки получил. Анализирую. Блин, да там чуть ли не каждый двадцатый-тридцатый alter упал. Почему ж так много-то? А, ну правильно, некоторые последующие завязаны на результаты предыдущих. Причины падения первых могут быть разные - отсутствие привилегий (а ведь наш dba клялся и божился, что тестовое окружение соответствует продовому), нехватка места, квот (на тесте данных было мало, а необходимый объем табличного пространства для индекса на проде мы оценить забыли). Ну ладно, привилегий додали, места добавили/квоты повысили. Конечно, gitora здесь не виноват, здесь виноваты мы, не досмотрели. Но давайте посмотрим, как мы будем выходить из этой ситуации. Что делать дальше?
    http://blog.gitora.com/tag/documentation/
    This way, the same GITORA_MODEL package can be executed many times even if contains DDL statements that are previously executed in the target database (because these statements will silently fail)
    Вот те на. 5 баллов! Как мне в результате повторного наката определить: упал alter по той же причине, по которой упал в первый раз, или упал потому, что уже выполнился в первый раз? А-а-а, уже знаю что вы скажете: в log-е есть SQLErrm и dbms_utility.format_error_backtrace - анализируй. Хорошо, пойду писать нетривиальный реглярус, чтобы выдернуть только нужные. Не то что в полчаса, и в час-два времени простоя могу не уложиться.

    Вторая сторона абсурдности повторного запуска пакета - вот дернул меня черт добавить в релиз пересоздание индекса с дополнительной колонкой - имя индекса менять не хотелось - много где хинтами прибито. А это два удачно выполнившихся на предыдущем шаге изменения - drop и create. Ну, надеюсь, drop отработает быстро. А create - мне опять сортировку по полному объему таблицы ждать?

    Напрашивается выход - аккуратненько из кода пакета после каждого наката выпиливать удачно выполнившиеся изменения (согласно логу) - только бы не ошибиться, с продом ведь работаю, во время простоя не укладываюсь, тороплюсь, нервничаю. Даже боюсь представить, что будет, если ошибусь.

    Не раскрыта тема DML-обновлений. Кейс - я хочу добавить поле, заполнить его чем-то (DML: merge или update), а потом сделать его notnull-ным и уникальным. Мне руками вставлять DML в автосгенеренный пакет при каждом коммите?

    Резюме: в общем, если у тебя все удачно накатилось с первого раза - считай повезло. Если вылазят ошибки - то с этим инструментом я тебе не завидую.

    P.S. По поводу того, что падение применения изменений не останавливает, а продолжает накат - я на вскидку не смог придумать сценария, когда удачное выполнение какого-то DDL после неудачного предыдущего DDL приводит к коллизиям.
    С DML-ем все понятно, при падении одного DML все последующие DML запускать нельзя, потому что они могут быть завязаны на результаты первого и выполниться "удачно" (либо запускать только те, что не имеют зависимостей с упавшим).

    А вот с DDL: поясню, что имею в виду.
    Пусть у нас есть два последовательных изменения, которые согласно скрипту наката должны довести систему до состояния STATE1.
    STATE0 -> DDL1 -> DDL2 -> STATE1
    Но в результате первого запуска первый упал, но удачно выполнился второй. Мы устранили причину падения первого и перенакатили. В результате имеем:
    STATE0 -> DDL2 -> DDL1 -> STATE1'.
    Задумался, есть ли такие DDL1 и DDL2, при которых STATE1 != STATE1'? Что-то не могу придумать, если кто знает, поделитесь идеей.
    30 сен 17, 15:09    [20833406]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    AmKad
    Задумался, есть ли такие DDL1 и DDL2, при которых STATE1 != STATE1'? Что-то не могу придумать, если кто знает, поделитесь идеей.
    Есть сценарий, при разных исходных состояниях теста и прода: на тесте индекс был, а на проде не было (хотя это само по себе уже косяк), состояние теста = STATE0, а состояние прода = STATE0'.

    Drop/create index. На тесте все прошло по хронологи: дропнули, создали. А на проде drop упал, прошел create как DDL2, а потом drop как DDL1. Случай вырожденный, немного не соответствует поставлененому мною вопросу, но все равно неприятный.
    30 сен 17, 15:22    [20833417]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    Elic
    Member

    Откуда: 1984. Выбраковка финно-угром продолжается. КЯЗ
    Сообщений: 28026
    AmKad
    Позволю себе попридираться.
    Всё ещё веришь в золотую пулю?
    Конкурентный контроль версий в многопользовательской БД - это фикция.
    30 сен 17, 15:41    [20833431]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    dmdmdm
    Member

    Откуда: Нижний Новгород
    Сообщений: 1041
    на вскидку не смог придумать сценария, когда удачное выполнение какого-то DDL после неудачного предыдущего DDL приводит к коллизиям.


    create role/table/view
    grant на это дело

    Конечно, после устранения причины скрипт повторно накатится. DDL можно философски рассматривать как DML словаря :)

    За анализ тулзы спасибо.

    Основной вывод - без контроля глазами никаким тулзам верить нельзя, и в SVN храним просто PL/SQL код, как и любой другой.
    30 сен 17, 16:06    [20833447]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    dmdmdm
    create role/table/view
    grant на это дело
    Это не соответствует постановке моего вопроса - в данном случае второй ddl не пройдет, если не прошел первый.
    30 сен 17, 22:30    [20833864]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    Elic
    Всё ещё веришь в золотую пулю?
    Конкурентный контроль версий в многопользовательской БД - это фикция.
    В золотую пулю конечно нет.
    Меня интересует не столько вопрос ведения версий БД в СКВ в плане хранения PL/SQL кода, сколько вопрос согласованного наката изменений схемы на Dev-Test-Prod контура. Именно поэтому я акцентировал внимание на методе применения alter-ов, предлагаемом в gitora. Допускаю, что у разных подходов могут быть свои плюсы и минусы, но хуже чем этот не придумаешь. Хотя, если продукт развивается, вполне возможно, что когда-нибудь он станет более юзабельным.
    30 сен 17, 22:44    [20833882]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    Кроик Семён
    Member

    Откуда: СПб --> Dortmund
    Сообщений: 6132
    кстати, важную вещь вспомнил

    есть такой класс таблиц (термина не знаю), которые крайне редко меняются и содержимое которых как бы захардкорено. Типа
    1 - файл
    2 - папка
    3 - диск
    4 - ссылка

    так вот, содержимое таких таблиц жизненно важно для правильного функционирования приложений, т.к. в их код "вкомпилировано", что 1 это файл, 2 это папка и т.д. Получается, что эти данные так же важны для целостности базы+приложений, как и сами сущности в базе, хоть они и описываются не DDL a DML

    К чему я веду? Если содержимое этих таблиц (в виде INSERTов) не вести в специальном файле, то никакая автоматическая система не поможет. Потому что автоматическая система же не знает, какие таблицы заполнены обычными данными, а какие вот такими "захардкоренными"
    1 окт 17, 02:30    [20834067]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    AmKad
    Меня интересует не столько вопрос ведения версий БД в СКВ в плане хранения PL/SQL кода, сколько вопрос согласованного наката изменений схемы на Dev-Test-Prod контура.
    Набросал пример использования liquibase для наката sample-схемы HR. Любой желающий может скачать его и поиграться. Вот ссылки на репозиторий и пояснительную записку. Для того, чтобы понять пример, нужно хотя бы бегло ознакомиться описанием продукта.
    1 окт 17, 17:41    [20834702]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    AmKad
    Пусть у нас есть два последовательных изменения, которые согласно скрипту наката должны довести систему до состояния STATE1.
    STATE0 -> DDL1 -> DDL2 -> STATE1
    Но в результате первого запуска первый упал, но удачно выполнился второй. Мы устранили причину падения первого и перенакатили. В результате имеем:
    STATE0 -> DDL2 -> DDL1 -> STATE1'.
    Задумался, есть ли такие DDL1 и DDL2, при которых STATE1 != STATE1'? Что-то не могу придумать, если кто знает, поделитесь идеей.
    alter table set unused ...;
    alter table ... drop unused columns;
    

    Хотя пример не такой критичный, так как на бизнес-логику и приложение повлиять не должен.
    1 окт 17, 19:04    [20834773]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5065
    AmKad,

    Читал по диагонали.
    Я правильно понимаю, что цель в следующем:
    разработчики хаотично делают изменения и на определенном этапе (перед релизом) надо сгенерировать скрипт, который приведет исходную схему к измененному состоянию?

    То есть вместо того, чтобы каждый разработчик поддерживал свой DDL вручную сначала, все они "натворили", а потом пришел главный и собрал все в релиз.

    Ну так для этого в основных инструментах разработчика (toad, pl/sql dev, etc) есть инструменты сравнения схем.
    Генерируешь скрипт, допиливаешь руками. Здесь есть много примеров почему.
    1 окт 17, 21:04    [20834907]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    dbms_photoshop,

    Как собрать изменения в целостный пакет - это вопрос, к которому можно подойти с разных сторон. Можно, как ты предлагаешь, делать diff перед релизом и пилить его руками, а можно сразу класть изменения в нужном формате. Второй подход мне ближе.

    Но после этого, их еще надо накатить. Тут тоже разные подходы.
    1 окт 17, 23:50    [20835051]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5065
    AmKad,

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

    Видимо для того, чтобы автоматически генерировать релиз по изменениям, ну в таком случае я предложил бы потратить некоторое время и написать это самому.
    Будь то на powershell, perl, visual basic, да хоть pure command line.
    2 окт 17, 00:18    [20835103]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    dbms_photoshop
    Не совсем понятно зачем дополнительные приблуды в дополнение к системе контроля версий.
    Если б ты посмотрел мой пример, и те вопросы, которые я поднимал в отношении gitora, то наверное можно было бы говорить предметно.
    2 окт 17, 00:34    [20835123]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5065
    AmKad
    dbms_photoshop
    Не совсем понятно зачем дополнительные приблуды в дополнение к системе контроля версий.
    Если б ты посмотрел мой пример, и те вопросы, которые я поднимал в отношении gitora, то наверное можно было бы говорить предметно.
    Если убрать эмоциональный окрас из того поста - он бы стал раза в три короче.
    Но я таки напрягся и прочел его перед тем как писать предыдущее сообщение, но так и не понял твои трудности и причины использовать левые приблуды.
    Для логгирования проблема добавить whenever sqlerror и spool или что?

    Изменения состоят из изменений хранимого кода и DML + DDL.
    Ключевой момент, что DDL + DML имеет смысл делать re-runnable. То есть при повторном выполнении чтоб не было ошибок.
    Но без фанатизма - все 100500 причин по которым предыдущий скрипт упал учитывать не стоит.
    re-runnable нужен для упрощения разработки, а релиз будет накатываться однократно.

    Попытки применять изменения из разных веток на один environment? Тут Элик уже ответил.
    2 окт 17, 00:52    [20835145]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    dbms_photoshop,

    Ты смотрел мой пример с liquibase? Понял, чем он отличается от простого логгирования, whenever sqlerror, spool и как там решается вопрос re-runnable?
    2 окт 17, 01:30    [20835169]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    dbms_photoshop
    Member

    Откуда: sqlmdx.net
    Сообщений: 5065
    AmKad,

    Если бы мне было интересно получить фидбек по интересующему вопросу - я бы несколько иначе разговаривал.
    Больше не лезу. Хорошего дня. :))
    2 окт 17, 11:36    [20835804]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    dbms_photoshop
    AmKad,

    Если бы мне было интересно получить фидбек по интересующему вопросу - я бы несколько иначе разговаривал.
    Была тема СУБД. История изменений, где мы в дискутивной форме обсуждали этот вопрос. Правда она длинная, не уверен, станешь ли ты ее читать.
    dbms_photoshop
    Больше не лезу. Хорошего дня. :))
    Спасибо, и тебе успехов.
    2 окт 17, 12:28    [20835999]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    reql
    Guest
    AmKad
    AmKad
    Меня интересует не столько вопрос ведения версий БД в СКВ в плане хранения PL/SQL кода, сколько вопрос согласованного наката изменений схемы на Dev-Test-Prod контура.
    Набросал пример использования liquibase для наката sample-схемы HR. Любой желающий может скачать его и поиграться. Вот ссылки на репозиторий и пояснительную записку. Для того, чтобы понять пример, нужно хотя бы бегло ознакомиться описанием продукта.

    Спасибо, интересно
    2 окт 17, 23:38    [20837673]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    run09
    Member

    Откуда:
    Сообщений: 9
    AmKad,

    Привет! Посмотрел ваш пример, - спасибо!
    А как предполагается вносить изменения в исходные определения? тех же таблиц, к примеру.
    К примеру, в одном бранче через миграцию добавилась колонка, в другом изменилась длина поля и т.д.

    Если я эти изменения вношу в исходные файлы, то Liquibase ругается на изменение суммы.
    30 мар 18, 18:48    [21300517]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    Все последующие изменения схемы данных проносятся как отдельные chageset-ы. На изменение суммы LB ругается, чтобы никто задним числом после наката их не менял.
    1 апр 18, 11:29    [21302651]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    merch
    Member

    Откуда:
    Сообщений: 75
    run09
    Если я эти изменения вношу в исходные файлы, то Liquibase ругается на изменение суммы.


    если ты отдаешь отчет своим действиям, то можешь обновить контрольную сумму в DatabaseChangeLog на ожидаемую. Таким обычно страдают перфекционисты, глаза которых не могут видеть 20 changeSet-ов c альтерами.

    Но при таком говноподходе, можешь нажить себе врагов.
    2 апр 18, 11:39    [21304427]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    run09
    Member

    Откуда:
    Сообщений: 9
    AmKad,
    Понятно, спасибо.

    merch,
    20 Changeset-ов видеть не проблема. Получается, чтобы где-то развернуть копию (версию), нужно будет все изменения всегда хранить/применять.
    2 апр 18, 13:19    [21304944]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    run09
    Member

    Откуда:
    Сообщений: 9
    AmKad,
    Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы? С кодом понятно - он в файле, которые runOnChange.
    пока только видится только костыль: хранить каталог с миграциями, с "замороженным" первичным DDL, и отдельно каталог с первичным DDL+все изменения в нем,но не отслеживаемый LB..
    4 апр 18, 13:34    [21311659]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    run09
    Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы?
    Снимай метаданные с БД после наката. Либо веди модель в CASE-инструменте.
    4 апр 18, 14:04    [21311788]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    run09
    Member

    Откуда:
    Сообщений: 9
    AmKad
    run09
    Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы?
    Снимай метаданные с БД после наката.

    Эти метаданные ведь все равно должны лежать отдельно от LB. по сути это примерно то же что и вести изменения в нем. Спасибо!
    4 апр 18, 15:18    [21312003]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    run09
    Эти метаданные ведь все равно должны лежать отдельно от LB.
    Да.
    4 апр 18, 15:27    [21312034]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    run09
    Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы?
    Посмотри на DBDoc, может это то, что тебе нужно. Там и пример какой-то есть. Сам я пока не разбирался.
    10 апр 18, 11:47    [21325800]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    run09
    Member

    Откуда:
    Сообщений: 9
    AmKad,

    Спасибо. Пока решил административно разделить установку и миграции. Изменения вносить везде
    16 апр 18, 12:39    [21342136]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    run09
    Спасибо. Пока решил административно разделить установку и миграции. Изменения вносить везде
    Без регулярной сверки метаданных "установка" и "миграции" гарантированно разъедутся. Инфа 146%. На мой скромный вкус вносить руками изменения в два места - это лишняя работа.
    16 апр 18, 12:49    [21342155]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    run09
    Member

    Откуда:
    Сообщений: 9
    AmKad,

    С одной стороны да, двойная работа, с другой, я хотел бы регулярно поднимать "пустую" схему из "установки" . Я так понимаю, в случае только с одной "миграцией", мне нужно будет последовательно накатывать все изменения... Возможно, это и не проблема.... нужно подумать еще
    16 апр 18, 13:51    [21342370]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    AmKad
    Member

    Откуда:
    Сообщений: 4868
    run09
    Я так понимаю, в случае только с одной "миграцией", мне нужно будет последовательно накатывать все изменения...
    Это не так страшно, как может показаться на первый взгляд. Для тестирования времени наката с нуля я извратился следующим образом: снял метаданные с работающей БД в полторы сотни таблиц и сгенерил xml-файлы наката, в которых каждая таблица создается с одним полем. А далее все отдельные составляющие, такие как остальные поля (alter-ы), индексы + констраинты, комменты, засунул в отдельные changeset-ы. На каждый changeset один SQL-оператор и только один. Плюс recreatable-объекты: вьюхи, пакеты-процедуры и т.д.
    Полный накат с нуля на чистую схему составил чуть более 1 минуты. Повторный перезапуск выполнился за несколько секунд - при совпадении хешей changeset повторно не выполняется.
    16 апр 18, 14:17    [21342468]     Ответить | Цитировать Сообщить модератору
     Re: Version Control для pl/sql  [new]
    run09
    Member

    Откуда:
    Сообщений: 9
    AmKad
    run09
    Я так понимаю, в случае только с одной "миграцией", мне нужно будет последовательно накатывать все изменения...
    Это не так страшно, как может показаться на первый взгляд. Для тестирования времени наката с нуля я извратился следующим образом: снял метаданные с работающей БД в полторы сотни таблиц и сгенерил xml-файлы наката, в которых каждая таблица создается с одним полем. А далее все отдельные составляющие, такие как остальные поля (alter-ы), индексы + констраинты, комменты, засунул в отдельные changeset-ы. На каждый changeset один SQL-оператор и только один. Плюс recreatable-объекты: вьюхи, пакеты-процедуры и т.д.
    Полный накат с нуля на чистую схему составил чуть более 1 минуты. Повторный перезапуск выполнился за несколько секунд - при совпадении хешей changeset повторно не выполняется.

    Интересный подход. Спасибо, подумаю
    17 апр 18, 10:28    [21344523]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: 1 2 3      [все]
    Все форумы / Oracle Ответить