エンティティフレームワークの移行：Goステートメントのみを-Script出力に含める

Question

エンティティフレームワークの移行計画の一環として、データの移動をデバッグするために、スクリプトを生成するために-Scriptパラメータを使用することがよくあります。

このスクリプトをクエリアナライザに取り込んで、手動でテストするためにトランザクションでラップすることができました。

私はスクリプトを適切に実行するためにGo文が必要な状況に遭遇しました。 Goを適切な場所に出力するために、次のコードが移行に追加されました。

Sql("GO"); 

-Scriptを使用すると、適切な位置にGO文が追加されます。しかし、-Scriptは使用されません。私は例外を取得します...

System.Data.SqlClient.SqlException (0x80131904): Could not find stored procedure 'GO'. 

スクリプトにGoコマンドを追加する安全な方法はありますか？

Answer 1

internal sealed class Configuration : DbMigrationsConfiguration<Context> 
{ 
    public Configuration() 
    { 
     AutomaticMigrationsEnabled = false; 
     const string providerInvariantName = "System.Data.SqlClient"; 
     SetSqlGenerator(providerInvariantName, new BatchingMigrationSqlGenerator(GetSqlGenerator(providerInvariantName))); 
    } 

    protected override void Seed(Context context) 
    { 
    } 

} 

internal class BatchingMigrationSqlGenerator : MigrationSqlGenerator 
{ 
    private readonly MigrationSqlGenerator migrationSqlGenerator; 

    public BatchingMigrationSqlGenerator(MigrationSqlGenerator migrationSqlGenerator) 
    { 
     this.migrationSqlGenerator = migrationSqlGenerator; 
    } 

    public override IEnumerable<MigrationStatement> Generate(IEnumerable<MigrationOperation> migrationOperations, string providerManifestToken) 
    { 
     var migrationStatements = migrationSqlGenerator.Generate(migrationOperations, providerManifestToken).ToArray(); 
     foreach (var migrationStatement in migrationStatements) 
     { 
      migrationStatement.BatchTerminator = "GO"; 
     } 
     return migrationStatements; 
    } 
} 

Answer 2

私は最近まったく同じ状況にぶつかった。私のEFコードの移行では、しばしば新しいテーブルまたは列が導入されます.Sql（...）を使用したデータ移行は、新しいテーブル/列を参照したい場合もあります。あなたが指摘したように、EFコードの移行として実行すると、各ステートメントはDBへの個別のバッチとして発行されるように見え、したがって問題はありません。ただし、本番用のデプロイメントの制約を満たすために、コード・マイグレーションのセットをスプリントから単一スクリプト（-Scriptを使用）に変えて、デプロイメント・チームのための単一のSQLスクリプト・マイグレーションを提示します。このスクリプトファイルは、単一のコードの移行から1つのT SQLバッチを処理しようとしたために、後で説明するバッチで以前に定義された構造を参照しようとしたため、失敗することがあります。

：

私は特に、私はこれを緩和するために、今のところ撮影したが、ここで彼らは2つのアプローチのどちらか好きではありません。その時点で私が思うようになったら、コードの移行を2つのマイグレーションに分けて、スクリプト化されたときに2つ（またはそれ以上）の別々のバッチになるようにします。コードマイグレーションの開発中にこれが必要であるというフィードバックがなく、エラーが発生しやすいように思われるので、私はこれが好きではありません。

b。私が集計スクリプトを生成するとき、それらをスクラッチDBに対して実行してそれらを証明し、そのスクリプトに必要な箇所に手動で "GO"ステートメントを注入することになります。これは、戻って行かなくてはならない厄介なプロセスであり、コードマイグレーションを100％反映したものではなく、スクリプト出力をもたらします。

EFコードの移行のソースコードをまだ掘り下げておらず、なぜ "GO"をストアドプロシージャとして解釈するのか、ソースコードに何かがあるそれを避けるための指示を与えるための方法に。

Answer 3

-Scriptパラメータの有無にかかわらず移行を実行すると、2つの異なるConfigurationクラスが使用されました。私のConfigurationクラスのうちの1つでは、MigrationSqlGeneratorをカスタム実装にラップし、GOステートメントを追加します。

Answer 4

私が使用してきました：

public class MigrationScriptBuilder : SqlServerMigrationSqlGenerator 
{ 
#if !DEBUG 
    protected override void Generate(System.Data.Entity.Migrations.Model.SqlOperation sqlOperation) 
    { 
     Statement("GO"); 

     base.Generate(sqlOperation); 

     Statement("GO"); 
    } 
#endif 
} 

を、それがデバッグだときに、それはクラッシュしません。そして私はリリースモードからスクリプトを書いています。

Answer 5

これは私のために働いている：

（移行プロセスフロー）を使用することができます（他の回答に見られるように）

public class MigrationScriptBuilder : SqlServerMigrationSqlGenerator 
{ 
    public override IEnumerable<MigrationStatement> Generate(IEnumerable<MigrationOperation> migrationOperations, string providerManifestToken) 
    { 
     var statements = base.Generate(migrationOperations, providerManifestToken); 

     statements = statements.SelectMany(s => new[] { 
      s, 
      new MigrationStatement 
      { 
       Sql = "GO" 
      } 
     }).ToList(); 

     return statements; 
    } 
} 

DbContextの構成でこのような方法で：

public Configuration() 
    { 
     SetSqlGenerator("System.Data.SqlClient", new MigrationScriptBuilder()); 
    }