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

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

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

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

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

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

Откуда:
Сообщений: 4900
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
Сообщений: 5088
AmKad,

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

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

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

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

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

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

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

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

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

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

Откуда: sqlmdx.net
Сообщений: 5088
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

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

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

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

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

Откуда:
Сообщений: 4900
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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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