Комментарии 6
Всё хорошо и гладко, но только для чтения, как делать вставки в таблицы?
Вставки ничем не отличаются от обычного использования, без EBR. Версионирующее представление — это не что иное, как проекция на используемую таблицу, и допустимы все DML операции с ними, как с обычными таблицами. При этом никогда не поменяется план исполнения, просто потому что версионирующее представление содержит внутри себя одну и только одну таблицу, без каких-либо условий фильтраций, сортировок и прочих преобразований данных (единственная доп. возможность – alias на колонку навесить, т.е. по сути переименовать ее).
А если на одну таблицу только одна процедура по редактированию/вставки (а такой подход используется у нас), то проблема с тем, чтобы пробежаться по всем местам модификации данных при добавлении колонок, отпадает как таковая.
А если на одну таблицу только одна процедура по редактированию/вставки (а такой подход используется у нас), то проблема с тем, чтобы пробежаться по всем местам модификации данных при добавлении колонок, отпадает как таковая.
то есть DDL накатывает как раньше, просто код в новой версии который работает с новой колонкой не сможет работать пока DDL не будет применён, так?
Если вы о операциях DDL в паре с использованием версионирующих представлений, то пока не обновите версионирующее представление новая колонка не будет доступна в коде для использования. Смысл использования версионирующих представлений — защитить от инвалидации объекты PL/SQL при изменении таблиц (ну и плюс возможность скрывать колонки базовой таблицы от версии к версии), само представление при простом добавлении колонки не инвалидируется, а как следствие и все зависимые объекты в состоянии, готовом к использованию.
Спасибо за статью, будет очень интересно почитать продолжение. Сами смотрели на эту технологию (в основном для обновления кода). Но без автоматизации процессов, в ручном режиме, показалось слишком сложным следить за корректной версионностью объектов. Если бы это интегрировать с какой-то системой контроля версий…
Спасает ли использование EBR от локов во время/после компиляции на рабочей системе?
Спасает ли использование EBR от локов во время/после компиляции на рабочей системе?
Спасибо за отзывы, приятно понимать, что было полезно кому-то.
На счет контроля версий — тут наверно просто пометки в репозиториях какие-то делать, что вот такой вариант стоит в таком-то edition. Не знаю, насколько крупный проект и насколько это будет удобно, но если вы работаете с oracl'овой частью в отдельном репозитории, то проблем возникнуть не должно.
А по поводу локов…
Если вы устанавливаете обновления кода всегда в новом edtion, то локам на пакетах просто не откуда взяться, приложение еще никто не использует.
Вопрос в том, если вам, к примеру необходимо gtt таблицу расширить, а есть активные сессии, блокирующие ее. Решение видится в следующем: держать две gtt-шки и попеременно версионирующие представления «натравливать» на предполагаемую к использованию в новом edition.
На счет контроля версий — тут наверно просто пометки в репозиториях какие-то делать, что вот такой вариант стоит в таком-то edition. Не знаю, насколько крупный проект и насколько это будет удобно, но если вы работаете с oracl'овой частью в отдельном репозитории, то проблем возникнуть не должно.
А по поводу локов…
Если вы устанавливаете обновления кода всегда в новом edtion, то локам на пакетах просто не откуда взяться, приложение еще никто не использует.
Вопрос в том, если вам, к примеру необходимо gtt таблицу расширить, а есть активные сессии, блокирующие ее. Решение видится в следующем: держать две gtt-шки и попеременно версионирующие представления «натравливать» на предполагаемую к использованию в новом edition.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Edition-Based Redefinition: можно ли в production?