2014-02-12 4 views
12

Я использую Entity Framework Migrations для кода, который сначала управляет моей моделью базы данных. Он работает очаровательно, и я могу справиться до сих пор. Но теперь мне нужно добавить один триггер базы данных, и я бы хотел сделать это с помощью EF Migrations и не использовать отдельный sql-скрипт только для этого случая (это было бы непонятно для клиентов, особенно после того, как мы убедили их, что мы можем обрабатывать все с помощью EF Migrations). Мой триггер прямо вперед, и выглядит тис:Добавить триггер базы данных с Entity Framework Code Первые миграции

CREATE OR REPLACE TRIGGER [name] BEFORE UPDATE ON myTable ... 

Есть ли команда, чтобы добавить триггер EF переселении?

+0

Заканчивать решения я придумал: [EntityFramework.Triggers] (http://github.com/NickStrupat/EntityFramework.Triggers). Это тоже на NuGet. –

+0

Выглядит многообещающе. Знаете ли вы, если он поддерживает несколько систем баз данных (oracle, sql-сервер и т. Д.) – StefanG

+0

Я тестировал его только с помощью SQL Server, но все это построено поверх Entity Framework агрегированным агентом. Это зависит от 'DbContext'. –

ответ

23

Вы можете просто добавить метод метода Sql("SQL COMMAND HERE") к методу миграции вашей миграции Up. Не забудьте также добавить оператор drop к методу Down. Вы можете создать пустую миграцию, если вам нужно, просто запустив Add-Migration без каких-либо изменений в модели.

public partial class Example : DbMigration 
{ 
    public override void Up() 
    { 
     Sql("CREATE OR REPLACE TRIGGER [name] BEFORE UPDATE ON myTable ..."); 
    } 

    public override void Down() 
    { 
     Sql("DROP TRIGGER [name]"); 
    } 
} 
+1

Вы также можете добавить IF NOT EXISTS (выберите * from sys.triggers, где name = 'name'), в UP(), чтобы сделать его идемпотентным. – eoghank

+13

@eoghank. Я не уверен, что согласен. Идея миграции состоит в том, что они должны повторяться во всех направлениях и что поэтому они предотвращают эту ситуацию. Теоретически, если нам нужны проверки существования, мы неправильно используем миграцию - поскольку мы не проверяем существование таблиц, мы не должны запускать триггеры? –

+1

Для ядра EF используйте migrationBuilder.Sql («бла-бла ...»); – wye

Смежные вопросы