Есть некая эталонная база данных, с которой периодически надо накатывать изменения на остальные. Таблицы при этом не затрагиваются, т.е. синхронизации подлежат только представления, пакеты, процедуры, функции и триггера
Самый простой вариант это PLSQL Developer/Schema compare и свести схемы врукопашную. Но это не вариант.
Хочется что-то типа такого: открываем дерево схемы эталонной базы, помечаем галочками в списке объектов, что хотим выгрузить, выгружаем отмеченные объекты в файловую систему (одновременно эти же файлы можно поместить в Version Control), потом генерируем итоговый скрипт, который прогоняем на целевой базе.
Список предназначенных к синхронизации объектов схемы тоже хочется где-то сохранять, чтобы всякий раз не проделывать эту операцию вручную, и потом модифицировать, добавлять и удалять этот список.
PL/SQL Developer умеет выгружать/загружать список отмеченных объектов в некий файл формата OSF (Object Selection Filter), но там шибко неудобное GUI.
Есть ли какие-нибудь для этих целей инструменты поудобнее?
Здравствуйте, α, Вы писали:
α> Есть ли какие-нибудь для этих целей инструменты поудобнее?
Нужно взять за правило: поменял объект в схеме — сохранил в файл и закоммитил в VCS. Список измененных объектов должен храниться тоже в VCS, например, в локальном git бранче. А не в самой схеме, которая может легко накрыться. Тогда необходимость в сравнении схем отпадает.
Для сборки финального патча написать отдельный скрипт.
Hardware eventually fails. Software eventually works. ::: avalon/1.0.442
Здравствуйте, wildwind, Вы писали:
W>Нужно взять за правило: поменял объект в схеме — сохранил в файл и закоммитил в VCS. Список измененных объектов должен храниться тоже в VCS, например, в локальном git бранче. А не в самой схеме, которая может легко накрыться. Тогда необходимость в сравнении схем отпадает.
Это классический, но кмк не продуктивный способ разработчикам это полдня сидеть делать копипейст вместо того чтобы прямо в тестовой базе в девелопере открыть скрипт, внести правки и прогнать тесты; кроме того они забывчивые. А хотелось бы наладить прозрачную синхронизацию между текстом измененной DDL схемы и локальным репозиторием (svn-git-и т.п.). В PL/SQL developer-е также есть что-то типа проектов (бесполезная штука) и плагинов к SVN и GIT (но они также вынуждают сваливать изменения схемы в локальный файл вручную)
Здравствуйте, α, Вы писали:
α> Список предназначенных к синхронизации объектов схемы тоже хочется где-то сохранять, чтобы всякий раз не проделывать эту операцию вручную
Перечитал еще раз и озадачился — что это за список? Разве он не ограничивается только выбранными и измененными разработчиком объектами? А они в общем случае каждый раз разные.
Hardware eventually fails. Software eventually works. ::: avalon/1.0.442
Здравствуйте, α, Вы писали:
α> Это классический, но кмк не продуктивный способ
Это поначалу так кажется. Или если ты один кодишь и поддерживаешь единственную версию в продакшене.
α> разработчикам это полдня сидеть делать копипейст
Не понял, что за копипейст на полдня?
α> вместо того чтобы прямо в тестовой базе в девелопере открыть скрипт, внести правки и прогнать тесты;
...и нажать Ctrl+S.
α> кроме того они забывчивые.
Ну полностью этого никакой автоматизацией не исправить. Можно раздать им скрипт-напоминалку "какие объекты я менял сегодня".
α> А хотелось бы наладить прозрачную синхронизацию между текстом измененной DDL схемы и локальным репозиторием (svn-git-и т.п.).
Это имело бы смысл, если бы у каждого разработчика была своя персональная схема, и в ней можно было бы делать бранчи так же легко, как в Git. А если все работают в одной базе и схеме, то постоянно будут коллизии. "Мне надо потестить X, но ты сломал пакет Y! Я пока откачу его на старую версию, OK?" Знаем, проходили. Твой код это тот, который у тебя в файле или локальном репозитории. А в дев. базе в любой момент времени может быть что угодно.
В PL/SQL developer-е также есть что-то типа проектов (бесполезная штука) и плагинов к SVN и GIT (но они также вынуждают сваливать изменения схемы в локальный файл вручную)
И правильно делают.
Hardware eventually fails. Software eventually works. ::: avalon/1.0.442
разработчикам это полдня сидеть делать копипейст вместо того чтобы прямо в тестовой базе в девелопере открыть скрипт, внести правки и прогнать тесты; кроме того они забывчивые. А хотелось бы наладить прозрачную синхронизацию между текстом измененной DDL схемы и локальным репозиторием (svn-git-и т.п.). В PL/SQL developer-е также есть что-то типа проектов (бесполезная штука) и плагинов к SVN и GIT (но они также вынуждают сваливать изменения схемы в локальный файл вручную)
