CTP3: DMF. Продолжаем изучение. Группы политик и дачный сезон
Продолжение изысканий.
После того, как простой пример по запрещению написания неправильных слов на заборе окончился успехом, пришла в голову идея посмотреть, что же такое «пользовательские группы».
Принцип работы политик и групп примерно такой: мы на даче. У всех «правильных» садоводов- любителей на даче водятся всякие гвозди, шурупы, лопаты, молотки, топоры, веревки для подвязки, шланги, семена и т.д. Ну не валяется же это все по территории?
У хорошего дачника есть банка с гвоздями ( где только гвозди, но правда, разных размеров), банка с шурупами, коробка с мелким инструментом и уголок для садового инвентаря. Так вот эти банки, коробки и уголок – это наши группы. Если дачник хочет прибить гвоздь в бане, чтоб тот поработал как вешалка, то товарищ к объекту [баня] применяет политику [гвоздь] из группы [банка с гвоздями]. Если я не ошибаюсь, то facet ( он же аспект) в данном случае – «работа вешалкой».
[Гвоздь] может принадлежать только [банке с гвоздями]. Он не может в тоже самое время принадлежать группе [садовый инвентарь] или [банка с шурупами]. Попробуйте положить гвоздь в три разные банки одновреммено? Зато разные по размеру гвозди могут лежать в одной и той же банке. А группы [банка с шурупами] и [банка с гвоздями], в свою очередь, можно применять к объектам [баня], [дача] ( ну там, ремонт мелкий), стена и т.д.
Политики [лопата] и [шланг], по аналогии с примером выше, могут применяться к объекту [грядка] и принадлежать группе [угол].
Фух.. Уже кажется достаточно примеров. Я сам все понял.
Теперь перейдем к практике.
Попробуем создать политику, которая будет определять правило задания пути и имени базы данных, создаваемой на сервере.
Для этого для начала создадим условие ( в примере с дачником условием может быть - жена запилила: « вещи в бане валяются на полу. Перед людьми стыдно!». Вообще это одно из самых универсальных условий типа «жена»).
Имя: File Path Condition
Facet: Database Facet
Expression:
‘PrimaryFilePath’ NOT LIKE ‘ c:\SQL\MyDB%’
Далее, опишем политику:
Name: File Path Policy
Enabled – ставим галочку.
Condition: File Path Condition
Group: DB Group ( эту группу я просто только что создал, сказав 'New')
В поле «Applies to:» выбираем Server/Database
И говорим, что мы хотим следить за изменениями ( Check on changes)
Дело сделано. Осталось только проверить. Создаем базу DBtest_3где яростно нарушаем правило нами же созданное:
create database DBtest_3 on
(
Name = TheDB_Test3,
Filename ='c:\sql\thisisthe_test3.mdf'
)
И… “Command(s) completed successfully”!!
Что случилось? Можно было не копать грядку и не забивать гвоздь? Ничего не работает?
Обновим-ка в обозревателе картиночку.
И что видим?
Заметно красный крестик? Смотрим что там:
Итого: то, что мы злостно нарушили, не осталось не замеченным. Процесс создания базы не является «обратимым» - его нельзя откатить назад. Поэтому и команда выполнилась успешно и никаких разверзшихся небес. Отрадно, что появилось визуальной отображение конфликта того, что было сделано с заданной политикой.
Пока я играл с политиками и группами, я заметил следующий эффект: подписать под группы можно все базы, кроме системных. Т.е получается, что на системные базы распространяются все политики , приписанные к группе «по умолчанию». В то время как все остальные базы могут быть подписаны как на группу по умолчанию, так и на определенные пользователем.
В принципе, это кажется очень разумным шагом. Но на всякий случай было бы интересно, есть ли у кого идеи, почему данная реализация может быть неправильной?
