Читать онлайн «Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ». Страница 128

Триггер никогда не вызывается явно - активный триггер выполняется автоматически, когда заданная операция DML выполняется для его таблицы.

Перечислим преимущества использования триггеров.

* Автоматическое применение ограничения данных, чтобы убедиться, что пользователи вводят только допустимые значения в столбцы.

* Сокращение объема поддержки приложений, поскольку изменения триггеров автоматически отражаются на всех приложениях, которые используют связанные таблицы, без необходимости их повторной компиляции и сборки.

* Автоматическое протоколирование изменений таблиц. Приложение может использовать протоколирование изменений с помощью триггера, который вызывается при модификации таблицы.

* Автоматическое информирование об изменениях базы данных с помощью средств сообщения о событиях.

Триггеры могут быть использованы в комбинации с генераторами для реализации автоинкрементных ключей. Подробные инструкции вы можете найти в главе 31.

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

Расширения языка PSQL включают следующие языковые элементы:

* операторы BEGIN и END для выделения блоков кода, которые могут быть вложенными;

* операторы DECLARE VARIABLE для объявления локальных переменных;

* конструкция FOR SELECT <спецификация-выбора> INTO <список-переменных? DO инкапсулирует курсор SQL для выполнения цикла просмотра наборов. Циклы могут быть вложенными;

* циклы WHILE;

* оператор SUSPEND для пересылки строки в кэш строк;

* конструкция IF ... THEN и ELSE для ветвления в программе;

* оператор EXCEPTION <объявленное-имя-исключения> для вызова пользовательских исключений;

* необязательные блоки WHEN <условие-исключения> DO для перехвата и обработки исключений;

* POST_EVENT <строка> для передачи сообщений клиентам.

Firebird версии 1.5 и более поздние также поддерживает:

* оператор EXECUTE STATEMENT для выполнения специальных операторов DML и DDL в модуле;

* логические контекстные переменные UPDATING, INSERTING и DELETING;

* контекстная переменная ROW_COUNT для получения количества строк, полученных выполненным оператором DML в том же блоке;

* дополнительный синтаксис для EXCEPTION без аргументов - для повторного вызова исключений, а с необязательным текстовым аргументом - для передачи информации клиенту.

Существуют некоторые ограничения языка для кодов в модулях PSQL.

* Операторы, использующие подмножество языка определения данных (DDL) SQL Firebird, не разрешены в PSQL[111].

* Операторы управления транзакциями недопустимы в PSQL, потому что хранимые процедуры и триггеры всегда выполняются в контексте существующей клиентской транзакции, a Firebird не поддерживает вложенные транзакции.

* Некоторые другие типы операторов, зарезервированные для использования в других средах (например, в isql, скриптах или во встроенном SQL - см. следующий раздел). Допустимы все динамические операторы DML.

* Идентификаторы объектов метаданных, такие как имена таблиц, столбцов, просмотров или хранимых процедур, не могут передаваться хранимой процедуре или возвращаться хранимой процедурой в ее аргументах.

* Триггеры не могут получать или возвращать аргументы.

Следующие типы операторов не поддерживаются в триггерах и хранимых процедурах:

* операторы языка определения данных (т. е. операторы, начинающиеся с ключевых слов CREATE, RECREATE, ALTER или DROP; SET GENERATOR; DECLARE EXTERNAL FUNCTION: DECLARE FILTER);

* операторы управления транзакциями: SET TRANSACTION, COMMIT, COMMIT RETAIN,

ROLLBACK, SAVEPOINT, RELEASE SAVEPOINT, ROLLBACK TO SAVEPOINT;

* операторы ESQL: PREPARE, DESCRIBE, EXECUTE;

* операторы CONNECT/DISCONNECT и отправки операторов SQL другим базам данных;

* GRANT/REVOKE;

* EVENT INIT/EVENT WAIT;

* BEGIN DECLARE SECTION/END DECLARE SECTION;

* BASED ON;

* WHENEVER;

* DECLARE CURSOR;

* OPEN;

* FETCH;

* любые операторы, начинающиеся с ключевых слов SET и SHOW.

Обработчики исключений могут быть написаны, чтобы "съесть" ошибку, обрабатывая ее разными способами. Например, в итеративной подпрограмме входная строка, вызывающая исключение, необязательно должна приводить к остановке всего процесса. Обработка исключения внутри триггера или хранимой процедуры может позволить пропустить проблемную входную строку - например, поместив сообщение об ошибке в протокол в текстовый файл или в таблицу ошибок - и дав возможность продолжить дальнейшую обработку.

Код в модуле может обрабатывать ошибку в необязательном фрагменте кода, называемом блоком исключения, который является последовательностью операторов, заключенных в операторные скобки BEGIN и END, которым предшествует ключевое слово WHEN.

Необработанное исключение останавливает процесс, отменяет всю выполненную к этому моменту работу[112] и возвращает сообщение об ошибке приложению. Вы также можете написать код, вызывающий пользовательское исключение и останавливающий процесс. Вы можете обработать эту ошибку в вашем коде или остановить процесс и вернуть пользовательское сообщение клиентскому приложению. Если модуль является триггером, то операция DML, в которой появилась эта ошибка, также будет отменена. В базе данных вы можете создать столько пользовательских исключений, сколько вам нужно. Начиная с версии 1.5, вы можете использовать данные времени выполнения и конструировать тексты для ваших сообщений об исключениях "на лету".

Обработка исключений и ошибок подробно обсуждается в главе 32.

События Firebird являются "сигналами", которые модули PSQL могут накапливать в процессе выполнения для передачи клиентским приложениям, когда работа будет подтверждена. Клиентские приложения в сети могут прослушивать- с использованием обработчика сообщений- конкретные события, в которых они заинтересованы, без необходимости специального опроса наличия события.

Программирование с событиями и задание приложениям указания на их прослушивание рассматривается в главе 32.

Процедурам и триггерам могут быть предоставлены привилегии для специфических действий (SELECT, INSERT, DELETE и т.д.) к таблицам точно так же, как пользователям или ролям предоставляются привилегии. Не существует специального синтаксиса: используется обычный оператор GRANT, но в предложении то указывается триггер или процедура вместо пользователя или роли. Аналогичным образом привилегии процедур и триггеров могут отменяться оператором REVOKE.

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

Например, если пользователь выполняет UPDATE для таблицы А, что вызывает триггер, а триггер выполняет INSERT для таблицы в, то это действие будет допустимым, если пользователь имеет привилегии INSERT к этой таблице или триггер имеет привилегии INSERT к этой таблице.

Если у триггера или процедуры нет достаточных привилегий для выполнения их действий, Firebird вызывает ошибку SQL и устанавливает соответствующий код ошибки. Вы можете перехватить этот код ошибки в обработчике исключений точно так же, как и другие исключения. Информацию об операторах GRANT и REVOKE см. в главе 35.

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

Запрос приходит от одного из следующих объектов:

* от клиентского приложения, которое напрямую выполняет хранимую процедуру;

* от триггера, который выполняет хранимую процедуру. Сюда относятся и системные триггеры, являющиеся частью систем поддержания ссылочной целостности или ограничений CHECK;

* от другой хранимой процедуры, которая выполняет эту хранимую процедуру.

Однажды вызванный запрос к триггеру или хранимой процедуре сохраняется в кэше метаданных, пока существуют клиентские соединения с базой данных, независимо от того, использует ли какой-нибудь клиент этот триггер или хранимую процедуру. Не существует механизма убрать эти невыполняющиеся запросы из кэша метаданных. По этой причине изменения модулей PSQL являются "отложенными" в большей или меньшей степени в большинстве случаев. Возможность для клиентов видеть эти изменения отличается для Классического сервера и Суперсервера.