Модульное тестирование инструкций DDL, которые должны быть в транзакции

Question

Я работаю над приложением, которое использует встроенные механизмы аутентификации Oracle для управления учетными записями пользователей и паролями.Приложение также использует защиту на уровне строк.По сути, каждый пользователь, который регистрируется через приложение, получает имя пользователя и пароль Oracle вместо обычной записи в таблице "ПОЛЬЗОВАТЕЛИ".Пользователи также получают метки к определенным таблицам.Этот тип функциональности требует, чтобы выполнение инструкций DML и DDL было объединено во многих случаях, но это создает проблему, поскольку инструкции DDL выполняют неявные фиксации.Если ошибка возникает после выполнения инструкции DDL, управление транзакциями не будет выполнять откат всего обратно.Например, когда новый пользователь регистрируется в системе, может произойти следующее:

1. Начать транзакцию
2. Вставьте сведения о персонале в таблицу.(т.е.имя, фамилия и т.д.) -DML
3. Создайте учетную запись oracle (создайте пользователя testuser, идентифицированного паролем;) - неявная фиксация DDL.Транзакция завершается.
4. Начинается новая транзакция.
5. Выполните больше операций с DML-статами (вставки, обновления и т.д.).
6. Возникает ошибка, транзакция только откатывается к шагу 4.

Я понимаю, что приведенная выше логика работает так, как задумано, но мне сложно модульно тестировать этот тип функциональности и управлять им на уровне доступа к данным.У меня произошел сбой базы данных или возникли ошибки во время модульных тестов, которые привели к загрязнению тестовой схемы тестовыми данными, которые следовало откатить.Достаточно легко стереть тестовую схему, когда это произойдет, но я беспокоюсь о сбоях базы данных в производственной среде.Я ищу стратегии, чтобы справиться с этим.

Это приложение на Java / Spring.Spring обеспечивает управление транзакциями.

Answer 1

Вы должны использовать проверку подлинности Oracle proxy в сочетании с безопасностью на уровне строк.

Читать это: http://www.oracle.com/technology/pub/articles/dikmans-toplink-security.html

Answer 2

Прежде всего я должен сказать:плохая идея делать это таким образом.По двум причинам:

1. Соединения зависят от пользователя.Это означает, что вы в значительной степени теряете преимущества пула соединений.Он также не очень хорошо масштабируется.Если у вас одновременно подключено 10 000 пользователей, вы будете постоянно открывать и закрывать жесткие подключения (а не пулы мягких подключений).;и
2. Как вы обнаружили, создание и удаление пользователей - это DDL, а не DML, и, таким образом, вы теряете "транзакционность".

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

Что касается того, как решить вашу проблему, то в принципе вы не можете.То же самое, как если бы вы создавали таблицу или индекс в середине вашей последовательности.

Answer 3

Я не соглашусь с некоторыми предыдущими комментариями и скажу, что в использовании встроенной системы безопасности учетных записей Oracle есть много преимуществ.Если вам нужно дополнить это какой-то теневой таблицей пользователей с дополнительной информацией, как насчет того, чтобы поместить создание учетной записи Oracle в отдельный пакет, который объявлен PRAGMA AUTONOMOUS_TRANSACTION и возвращает статус успеха / неудачи пакету, который выполняет вставку в теневую таблицу?Я полагаю, что это изолировало бы создание учетной записи Oracle от транзакции.