|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
кстати, важную вещь вспомнил есть такой класс таблиц (термина не знаю), которые крайне редко меняются и содержимое которых как бы захардкорено. Типа 1 - файл 2 - папка 3 - диск 4 - ссылка так вот, содержимое таких таблиц жизненно важно для правильного функционирования приложений, т.к. в их код "вкомпилировано", что 1 это файл, 2 это папка и т.д. Получается, что эти данные так же важны для целостности базы+приложений, как и сами сущности в базе, хоть они и описываются не DDL a DML К чему я веду? Если содержимое этих таблиц (в виде INSERTов) не вести в специальном файле, то никакая автоматическая система не поможет. Потому что автоматическая система же не знает, какие таблицы заполнены обычными данными, а какие вот такими "захардкоренными" ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2017, 02:30 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKadМеня интересует не столько вопрос ведения версий БД в СКВ в плане хранения PL/SQL кода, сколько вопрос согласованного наката изменений схемы на Dev-Test-Prod контура.Набросал пример использования liquibase для наката sample-схемы HR. Любой желающий может скачать его и поиграться. Вот ссылки на репозиторий и пояснительную записку . Для того, чтобы понять пример, нужно хотя бы бегло ознакомиться описанием продукта . ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2017, 17:41 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKadПусть у нас есть два последовательных изменения, которые согласно скрипту наката должны довести систему до состояния STATE1. STATE0 -> DDL1 -> DDL2 -> STATE1 Но в результате первого запуска первый упал, но удачно выполнился второй. Мы устранили причину падения первого и перенакатили. В результате имеем: STATE0 -> DDL2 -> DDL1 -> STATE1'. Задумался, есть ли такие DDL1 и DDL2, при которых STATE1 != STATE1'? Что-то не могу придумать, если кто знает, поделитесь идеей. Код: plsql 1. 2.
Хотя пример не такой критичный, так как на бизнес-логику и приложение повлиять не должен. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2017, 19:04 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKad, Читал по диагонали. Я правильно понимаю, что цель в следующем: разработчики хаотично делают изменения и на определенном этапе (перед релизом) надо сгенерировать скрипт, который приведет исходную схему к измененному состоянию? То есть вместо того, чтобы каждый разработчик поддерживал свой DDL вручную сначала, все они "натворили", а потом пришел главный и собрал все в релиз. Ну так для этого в основных инструментах разработчика (toad, pl/sql dev, etc) есть инструменты сравнения схем. Генерируешь скрипт, допиливаешь руками . Здесь есть много примеров почему. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2017, 21:04 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
dbms_photoshop, Как собрать изменения в целостный пакет - это вопрос, к которому можно подойти с разных сторон. Можно, как ты предлагаешь, делать diff перед релизом и пилить его руками, а можно сразу класть изменения в нужном формате. Второй подход мне ближе. Но после этого, их еще надо накатить. Тут тоже разные подходы. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2017, 23:50 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKad, Ну так мне тоже ближе писать DDL вручную. Не совсем понятно зачем дополнительные приблуды в дополнение к системе контроля версий. Видимо для того, чтобы автоматически генерировать релиз по изменениям, ну в таком случае я предложил бы потратить некоторое время и написать это самому. Будь то на powershell, perl, visual basic, да хоть pure command line. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2017, 00:18 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
dbms_photoshopНе совсем понятно зачем дополнительные приблуды в дополнение к системе контроля версий.Если б ты посмотрел мой пример, и те вопросы, которые я поднимал в отношении gitora, то наверное можно было бы говорить предметно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2017, 00:34 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKaddbms_photoshopНе совсем понятно зачем дополнительные приблуды в дополнение к системе контроля версий.Если б ты посмотрел мой пример, и те вопросы, которые я поднимал в отношении gitora, то наверное можно было бы говорить предметно.Если убрать эмоциональный окрас из того поста - он бы стал раза в три короче. Но я таки напрягся и прочел его перед тем как писать предыдущее сообщение, но так и не понял твои трудности и причины использовать левые приблуды. Для логгирования проблема добавить whenever sqlerror и spool или что? Изменения состоят из изменений хранимого кода и DML + DDL. Ключевой момент, что DDL + DML имеет смысл делать re-runnable. То есть при повторном выполнении чтоб не было ошибок. Но без фанатизма - все 100500 причин по которым предыдущий скрипт упал учитывать не стоит. re-runnable нужен для упрощения разработки, а релиз будет накатываться однократно. Попытки применять изменения из разных веток на один environment? Тут Элик уже ответил. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2017, 00:52 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
dbms_photoshop, Ты смотрел мой пример с liquibase? Понял, чем он отличается от простого логгирования, whenever sqlerror, spool и как там решается вопрос re-runnable? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2017, 01:30 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKad, Если бы мне было интересно получить фидбек по интересующему вопросу - я бы несколько иначе разговаривал. Больше не лезу. Хорошего дня. :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2017, 11:36 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
dbms_photoshopAmKad, Если бы мне было интересно получить фидбек по интересующему вопросу - я бы несколько иначе разговаривал.Была тема СУБД. История изменений , где мы в дискутивной форме обсуждали этот вопрос. Правда она длинная, не уверен, станешь ли ты ее читать. dbms_photoshopБольше не лезу. Хорошего дня. :))Спасибо, и тебе успехов. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2017, 12:28 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKadAmKadМеня интересует не столько вопрос ведения версий БД в СКВ в плане хранения PL/SQL кода, сколько вопрос согласованного наката изменений схемы на Dev-Test-Prod контура.Набросал пример использования liquibase для наката sample-схемы HR. Любой желающий может скачать его и поиграться. Вот ссылки на репозиторий и пояснительную записку . Для того, чтобы понять пример, нужно хотя бы бегло ознакомиться описанием продукта . Спасибо, интересно ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2017, 23:38 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKad, Привет! Посмотрел ваш пример, - спасибо! А как предполагается вносить изменения в исходные определения? тех же таблиц, к примеру. К примеру, в одном бранче через миграцию добавилась колонка, в другом изменилась длина поля и т.д. Если я эти изменения вношу в исходные файлы, то Liquibase ругается на изменение суммы. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.03.2018, 18:48 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
Все последующие изменения схемы данных проносятся как отдельные chageset-ы. На изменение суммы LB ругается, чтобы никто задним числом после наката их не менял. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.04.2018, 11:29 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
run09Если я эти изменения вношу в исходные файлы, то Liquibase ругается на изменение суммы. если ты отдаешь отчет своим действиям, то можешь обновить контрольную сумму в DatabaseChangeLog на ожидаемую. Таким обычно страдают перфекционисты, глаза которых не могут видеть 20 changeSet-ов c альтерами. Но при таком говноподходе, можешь нажить себе врагов. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 11:39 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKad, Понятно, спасибо. merch, 20 Changeset-ов видеть не проблема. Получается, чтобы где-то развернуть копию (версию), нужно будет все изменения всегда хранить/применять. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.04.2018, 13:19 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKad, Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы? С кодом понятно - он в файле, которые runOnChange. пока только видится только костыль: хранить каталог с миграциями, с "замороженным" первичным DDL, и отдельно каталог с первичным DDL+все изменения в нем,но не отслеживаемый LB.. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2018, 13:34 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
run09Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы?Снимай метаданные с БД после наката. Либо веди модель в CASE-инструменте. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2018, 14:04 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKadrun09Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы?Снимай метаданные с БД после наката. Эти метаданные ведь все равно должны лежать отдельно от LB. по сути это примерно то же что и вести изменения в нем. Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2018, 15:18 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
run09Эти метаданные ведь все равно должны лежать отдельно от LB.Да. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2018, 15:27 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
run09Как тогда, посмотрев в SVN, увидеть актуальную версию таблицы?Посмотри на DBDoc , может это то, что тебе нужно. Там и пример какой-то есть. Сам я пока не разбирался. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2018, 11:47 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKad, Спасибо. Пока решил административно разделить установку и миграции. Изменения вносить везде ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 12:39 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
run09Спасибо. Пока решил административно разделить установку и миграции. Изменения вносить вездеБез регулярной сверки метаданных "установка" и "миграции" гарантированно разъедутся. Инфа 146%. На мой скромный вкус вносить руками изменения в два места - это лишняя работа. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 12:49 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
AmKad, С одной стороны да, двойная работа, с другой, я хотел бы регулярно поднимать "пустую" схему из "установки" . Я так понимаю, в случае только с одной "миграцией", мне нужно будет последовательно накатывать все изменения... Возможно, это и не проблема.... нужно подумать еще ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 13:51 |
|
Version Control для pl/sql
|
|||
---|---|---|---|
#18+
run09Я так понимаю, в случае только с одной "миграцией", мне нужно будет последовательно накатывать все изменения...Это не так страшно, как может показаться на первый взгляд. Для тестирования времени наката с нуля я извратился следующим образом: снял метаданные с работающей БД в полторы сотни таблиц и сгенерил xml-файлы наката, в которых каждая таблица создается с одним полем. А далее все отдельные составляющие, такие как остальные поля (alter-ы), индексы + констраинты, комменты, засунул в отдельные changeset-ы. На каждый changeset один SQL-оператор и только один. Плюс recreatable-объекты: вьюхи, пакеты-процедуры и т.д. Полный накат с нуля на чистую схему составил чуть более 1 минуты. Повторный перезапуск выполнился за несколько секунд - при совпадении хешей changeset повторно не выполняется. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.04.2018, 14:17 |
|
|
start [/forum/topic.php?fid=52&startmsg=39528928&tid=1880830]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 175ms |
0 / 0 |