Модульное тестирование операторов DDL, которые должны быть в транзакции - PullRequest
Новая
       51

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

0 голосов
/ 21 мая 2009

Я работаю над приложением, которое использует встроенные в Oracle механизмы аутентификации для управления учетными записями пользователей и паролями. Приложение также использует безопасность на уровне строк. По сути, каждый пользователь, который регистрируется через приложение, получает имя пользователя и пароль Oracle вместо обычной записи в таблице «USERS». Пользователи также получают ярлыки на определенных таблицах. Для этого типа функциональности требуется, чтобы во многих случаях выполнялись операторы DML и DDL, но это создает проблему, поскольку операторы DDL выполняют неявные фиксации. Если ошибка произойдет после выполнения инструкции DDL, управление транзакциями не откатит все назад. Например, когда новый пользователь регистрируется в системе, может произойти следующее:

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

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

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

Ответы [ 3 ]

2 голосов
/ 21 мая 2009

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

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

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

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

1 голос
/ 21 мая 2009

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

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

0 голосов
/ 21 мая 2009

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

...