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