2

私はこれについて何時間も頭を悩ませてきましたが、何が悪いのか理解できないようです.


プロジェクトの基本設定は次のとおりです。

  • ASP.NET メンバーシップを使用した MVC 3.0 プロジェクト
  • Entity Framework 4.3、Code First アプローチ
  • ローカル環境: 2 つの MDF データベース ファイルが接続されたローカル SQL Server (aspnet.mdf + entities.mdf)
  • サーバー環境: Windows Azure + 2 つの SQL Azure データベース (aspnet とエンティティ)


行ったことは次のとおりです。

  • ローカル データベースとリモート データベースを作成し、デバッグ モードで SQLEXPRESS 接続文字列を使用し、リリース モードで SQL Azure 接続文字列を使用するように web.config を変更しました。
  • データをシードするメソッドでSampleData拡張するクラスを作成しました。DropCreateDatabaseAlways<Entities>Seed
  • データベースにデータをシードするために使用System.Data.Entity.Database.SetInitializer(new Models.SampleData());されます。Application_Start
  • アプリをローカルで実行しました-テーブルが作成され、シードされました。すべて問題ありません。
  • リモートアプリをデプロイして実行しました-テーブルが作成され、シードされました。すべて問題ありません。

  • リモート Azure 環境でアプリケーションを起動するたびにエンティティ データベースの破棄を停止するプリプロセッサ ディレクティブを追加しました。

    #if DEBUG
    System.Data.Entity.Database.SetInitializer(new Models.SampleData());
#else
    System.Data.Entity.Database.SetInitializer<Entities>(null);
#endif


ここが醜くなったところです

  • NuGet を使用して移行を有効にしました。AutomaticMigrationsEnabled = true;
  • すべてがスムーズで快適に動作していました。数日間調理したままにしました

  • 本日、Azure 環境に未知のバグがあることに気付きました。

    • スーパークラスから派生したいくつかのクラスがありますSuperClass
    • 対応するエンティティ テーブルは、これらすべてのオブジェクトを同じSuperClassテーブルに格納し、さまざまなクラスをロードするときにどの列からフィードするかを識別するために識別子を使用します。

    • ロードは今日までは問題なく行われていましたが、今はそうではありません。次のエラー メッセージが表示されます。

      The 'Foo' property on 'SubClass1' could not be set to a 'null' value. You must set this property to a non-null value of type 'Int32'.
    • 簡単なチェックの後、SuperClassテーブルには列FooとがありますFoo1。SuperClassには 2 つのサブクラスSubClass1とがありSubClass2、それぞれにFooプロパティがあるため、十分に論理的です。私たちの場合Fooは NULL ですFoo1が、int32値があります。したがって、問題はデータベースにあるのではなく、モデルとデータベースの間のリンクが失われたように見えます。ディスクリミネーターのロジックが破損しています。

  • 何がうまくいかなかったのかについての兆候を見つけようとして、いくつかのことに気付きました。

    • SQL Azure Entity データベースで移行を実行したことはありませんが、データベースには現在_MigrationHistoryテーブルがあります

    • _MigrationHistoryテーブルには 1 つのレコードがあります。

      MigrationID: 201204102350574_InitialCreate
CreatedOn: 4/10/2012 11:50:57 PM
Model: <Binary data>
ProductVersion: 4.3.1

    • 他のテーブルを見ると、この移行が行われたときにそれらのほとんどが空になっていました。最初にシードされたテーブルのみがSampleDataそのまま残りました。

    • SQL Azure 管理ポータルでチェックインすると、エンティティ データベースは次の作成日を示しています: 2012 年 4 月 10 日 23:50:55。


ここに私たちの理解があります

  • 何らかの理由で、SQL Azure によってデータベースが削除され、再作成されました
  • このプロセスで _MigrationHistory テーブルが作成され、将来の移行のためにモデルをテストするための開始点が登録されました。


ここに私たちの質問があります

  • 誰が / 何がデータベースの削除 / 再作成を引き起こしたのですか?
  • Application_StartEF はサンプル データをどのように再シードできSystem.Data.Entity.Database.SetInitializer<Entities>(null);ますか?

編集:何が問題なのかを調べたところ、この SQL AzureチュートリアルPersistSecurityInfoで考慮しなかったことが 1 つあります。それは、データベースの作成後に SQL Azure エンティティ データベース接続文字列から削除しなかったことです。なぜ地球上でそれが問題を引き起こしたのかわかりませんが、それでも言及する価値があります...

4

1 に答える 1

0

問題の原因が見つかりました。ご不明な点がある場合は、プリプロセッサ ディレクティブを追加してから Azure をデプロイしていません。MS は、VM が常駐していたマシンを再起動したに違いありません。新しい VM は、参照データを使用してデータベースを再作成しました。

得られた教訓: 常に頻繁に Azure のデプロイを行います。

于 2012-04-14T00:48:35.127 に答える