MS SQL Server 9 Yukon. Интеграция с .NET (стр. 6 из 6)
Для DML-триггеров доступно также свойство bool[] ColumnsUpdated – массив флагов, определяющих, какие из колонок подверглись изменению. Аналогичная функциональность в триггерах T-SQL достигается при помощи функции UPDATE().
Прямого доступа к псевдотаблицам inserted и deleted нет; но их можно прочитать используя SqlCommand, полученную уже знакомым нам методом GetCommand() класса SqlContext.
Вот полный текст класса, в котором объявлены оба триггера:
| using System; using System.Data; using System.Data.Sql; using System.Data.SqlServer; using System.Data.SqlTypes; using System.Text.RegularExpressions; public class CTriggerTest { [SqlTrigger ("DATABASE", "AFTER CREATE_TABLE")] public static void AttachAnotherTrigger() { SqlTriggerContext ctx = SqlContext.GetTriggerContext(); Regex p = new Regex("<object>(?<tablename>.*)</object>", RegexOptions.IgnoreCase); string xml = ctx.EventData.ToSqlString().Value; string tableName = p.Match(xml).Groups["tablename"].Value; SqlContext.GetPipe().Send(String.Format("Table {0} created\n", tableName)); using (SqlCommand cmd = SqlContext.GetCommand()) { cmd.CommandText = String.Format( @"create trigger {0}_insert on {0} for insert as external name TestingYukon:CTriggerTest::AnotherTrigger", tableName); cmd.ExecuteNonQuery(); } } public static void AnotherTrigger() { SqlContext.GetPipe().Send("Row Insert Intercepted\n"); } } |
Как нетрудно заметить, никакого атрибута методу AnotherTrigger не назначено – мы регистрируем его вручную. Кстати, еще одним преимуществом триггеров на .NET-языках по сравнению с T-SQL является возможность назначить одно и то же тело на различные объекты.
Я включил в этот раздел результаты некоторых экспериментов с MS SQL Server Yukon, которые не очень хорошо вписываются в общую структуру статьи.
Одним из наиболее интересных нововведений в .NET 1.2 являются Generic-и. Они позволяют облегчить повторное использование кода, вместе с тем повышая надежность приложений.
Поскольку программирование под Yukon требует именно этой версии .NET, логично поинтересоваться перспективами использования в нем данного новшества.
Увы, напрямую использовать Generic-тип в Yukon нельзя. В одном из своих первых экспериментов я пытался создать обобщенную агрегирующую функцию. Такой подход кажется вполне логичным – многие агрегирующие функции естественным образом обобщаются на произвольные типы данных. В примере, который я привел в данной статье, функция AvgGeom принимает и возвращает SqlDouble. При ее применении к числам с фиксированной запятой возникают ненужные накладные расходы на преобразование типов во время выполнения запроса. Писать же по версии этой функции для каждого числового типа – расточительно и просто скучно.
Однако, попытка зарегистрировать generic-класс в качестве агрегирующей функции не удалась. Такие классы Yukon просто «не видит». Это, в общем-то, логично – насколько мне известно, обязанность генерации «окончательного» класса по его generic-прототипу лежит на компиляторе. А его-то как раз в сервере нет! Поэтому использование конструкций вида GenericType<SQLDecimal> в параметре EXTERNAL NAME любого из операторов CREATE лишено смысла.
Следующим шагом стала попытка предоставить серверу обычный класс, унаследованный от специализированной generic-реализации. Увы, это тоже не привело к успеху – сервер «не видит» публичные унаследованные методы. Последним ударом в этот бубен стала такая попытка:
| public new void Init() { base.Init(); } |
Это был фактически жест отчаяния – уже необходимость специализировать класс для каждого типа аргументов убивает всю красоту обобщенного программирования. А уж написание рутинного кода лишь немногим лучше содержания зоопарка функций-близнецов. Получившийся в итоге класс удалось, наконец, «протащить» сквозь регистрацию. К сожалению, пользы от этого было немного – при попытке использовать функцию в запросе сервер нашел оба метода и пожаловался на неоднозначность.
| ПРИМЕЧАНИЕ В данный момент это выглядит как простая недоработка. Возможно, это поведение будет исправлено в финальной версии. |
Кстати, обратите внимание, что необходимая функциональность класса агрегирующей функции не выражена в терминах какого-либо интерфейса – это связано именно с тем, что типы параметров могут меняться. В терминах generic можно было бы выразить этот гипотетический интерфейс примерно так:
| public interface IAggregating<input_type, return_type> : INullable { void Init(); void Accumulate(input_type value); return_type Terminate(); void Merge(IAggregating<input_type, return_type> other); } |
Однако разработчики Yukon проигнорировали эту возможность. В итоге, пригодность класса для реализации агрегирующей функции проверяется только на этапе его регистрации в базе данных.
Перспектива внедрения .NET-кода в SQL Server заинтересовала меня в первую очередь возможностями ООП, которого так остро порой не хватает в RDBMS. Однако радость моя оказалась преждевременной – из инкапсуляции, наследования и полиморфизма поддерживается только первая парадигма. Наследование и полиморфизм приходится оставить «за дверью», т.е. по ту сторону оператора CREATE ASSEMBLY.
Во-первых, в Yukon типы совместимы только сами с собой и с binary. Это означает, что если колонка в таблице продекларирована как TypeA, то никаких наследников этого типа туда положить нельзя. Увы. При регистрации в базе отношения между классами исчезают.
Во-вторых, полиморфизм в смысле виртуальных методов подразумевает поддержку наследования, а ее-то как раз и нету. То есть виртуальные методы в Yukon ничем не лучше невиртуальных. Даже самый тоталитарный вариант полиморфизма – перегрузка методов – не работает. В пользовательском типе нельзя использовать более одного публичного члена с заданным именем (то есть иметь можно, но попытка обращения к нему приведет к ошибке).
Использовать индексеры в рамках T-SQL нельзя. По крайней мере, способа это сделать я не нашел. Увы.
Поддержка .NET-триггеров для метаданных вкупе с возможностью использовать бинарное представление сборки в операторе CREATE ASSEMBLY открывает широкие перспективы метапрограммированию. Я не экспериментировал с этой функциональностью, но теоретически кажется осуществимой разработка мета-кода, который будет динамически формировать сборки и классы при наступлении различных событий, поддерживая, таким образом, более сложные взаимосвязи между объектами базы данных, чем предоставлены Microsoft. Сценарии развертывания теперь могут быть практически неограниченно сложными, при внешней простоте. Одним из самых простых вариантов мне видится триггер на оператор CREATE ASSEMBLY, который будет анализировать содержимое сборки на предмет классов, размеченных соответствующими атрибутами, и выполнять автоматическую регистрацию соответствующих объектов в базе данных.
Не так давно в форуме RSDN промелькнула ссылка на статью Эндрю Айзенберга и Джима Мелтона,
SQL-программы, использующие язык программирования JAVA, опубликованную издательством OSP почти пять лет назад. В ней упоминается стандарт SQL/PSM, предложенный в 1996 году. Как ни странно, но синтаксис новых конструкций T-SQL во многом похож на предлагаемый в этом стандарте. Основное отличие касается отсутствия параметра language, которое, скорее всего, объясняется неразличимостью языков в .NET. Это можно понять как намерение Microsoft поддерживать вавилонское столпотворение «снаружи» сервера, нивелируя языковые различия благодаря природе .NET.Список литературы
Microsoft Development Environment Whidbey (8.0.30703.4),
Microsoft .NET Framework 1.2 (1.2.30703),
Microsoft SQL Server Yukon (9.00.608)
Microsoft Word 2003 (11.5604.5703)
Nescafe Gold (ТУ 9198-330-605473-98)
RSDN Authoring Pack (3.1)
Основная информация по теме статьи находится в MSDN и SQL Server Books Online.