問題タブ [entity-framework-migrations]

以前は、Code Firstを使用してテーブルを作成するときに、データベース初期化子を使用してテーブルをシードまたは事前入力していました。これはすべてうまくいきましたが、EF4.3移行の使用に移りたいと思いました。

プロジェクトでEF4.3に更新し、データベース初期化コードを削除して、migrationsConfiguration.csファイルのSeedメソッド内に配置しました。これは、デフォルトのユーザーをユーザーテーブルにシードする場合を除いて、テーブルに事前入力することですべて問題なく機能しています。

Seedメソッド内で次のコードを使用します:(この状況での使用方法がわからないため、現在、これはAddOrUpdateコードを使用していません-したがって、ユーザー名チェック）

Update-Databaseを実行しようとすると、次のエラーが発生します。

これは私がCreateUserを呼び出す方法にかかっていると思いますが、このバグを回避する方法を理解できないようです。セキュリティの質問と回答にnullだけを入れてみましたが、うまくいかないようです。

'AddOrUpdate'オプションを使用してユーザーをシードする例はありますか？

編集1：

以下のコメントの1つに従って、私はAltairisSecurityToolkitを使用してメンバーシップを管理しています。私のweb.configは次のように設定されています。

編集2：

また、これをAltairisフォーラムのオープンチケットとして公開しました。 http://altairiswebsecurity.codeplex.com/workitem/32273

編集3：

これをエラーなしで機能させるには、次のようにコードを設定する必要がありました。

Update-Databaseを実行すると、上記はコンパイルされますが、新しいユーザーは生成されません。誰かが試すための提案があれば、それは素晴らしいことです！

ありがとう、

リッチ

Update-Database最近、Entity Frameworkの移行を使用し始めましたが、コマンドを実行したときにデータベース名がプルスルーされないことに気付きました。

私の接続文字列は次のとおりです。

Update-Databaseを初めて実行すると、データベースは正しい名前TestDBで作成されます。ただし、エンティティの1つに変更を加えるとすぐに、スタートアッププロジェクト名を追加しない限り更新されなくなります（マルチプロジェクトソリューションを使用しています）。

これにより、移行で常に使用され続ける別の新しいデータベースが作成されます。StartUpProjectNameコマンドを入力する必要はありませんが、これによって生成されるデータベースのデフォルト名を上書きする方法はありますか？常にデータベースを次のように作成します

StartUpProject名を渡すときに作成されたデータベースが単にTestDBと呼ばれるようにする方法はありますか、それともこれはStartUpProjectName設定の使用の制限ですか？

注として、StartUpProjectNameを指定する必要があるのは、多層プロジェクトをセットアップしているためだと思います。移行構成ファイルは「データ」プロジェクトにあり、エンティティ/モデルは「ドメイン」プロジェクトにあります。また、以前使用していたように、Global.asax.csファイルには現在初期化オプションがありません。最初のef4.2をコーディングします。したがって、私のプロジェクトでは、データプロジェクトにDataContextがあり、そのプロジェクトにも移行構成があります。

編集：

私は最初にこの質問を設定して以来、マルチプロジェクトソリューションでデータベースに名前を付ける「正しい」方法に出くわしました。以下の答えは機能しますが、理想的なソリューションではない別の領域でweb.configを複製していることを意味します。代わりに、次のようにして名前をDbContextに入れることができます（DataContextは、プロジェクトで使用した名前です）。

ありがとう、

リッチ

私は既存のデータベースで Entity Framework 4.3 を使用しており、対応しようとしているシナリオがいくつかあります。

まず、データベースを削除した場合、EF で最初から再作成したいと思います。これには、CreateDatabaseIfNotExists データベース初期化子を正常に使用しました。

次に、モデルを更新し、データベースが既に存在する場合、データベースを自動的に更新したいと考えています。これには Entity Framework 4.3 Migrations を使用しました。

だからここに私の質問があります。いくつかの参照データを必要とする新しいテーブルをモデルに追加するとします。データベース初期化子の実行時と移行の実行時の両方でこのデータが確実に作成されるようにする最善の方法です。私の望みは、データベースを最初から作成しているときにデータが作成され、移行の実行の結果としてデータベースが更新されたときにも作成されることです。

いくつかの EF 移行の例では、人々が移行の UP メソッドで SQL() 関数を使用してシード データを作成するのを見てきましたが、可能であれば、コンテキストを使用してシード データを作成したいと思います (ほとんどのデータベース初期化子の例で見られるように)。 EFの全体的なアイデアがそれを抽象化しているときに、純粋なSQLを使用するのは奇妙に思えます。UP メソッドでコンテキストを使用しようとしましたが、何らかの理由で、テーブルを作成する呼び出しのすぐ下にシード データを追加しようとすると、移行で作成されたテーブルが存在するとは見なされませんでした。

どんな知恵も大歓迎です。

実稼働サイトで Entity Framework 4.3 の移行を使用することを検討しています。以下が私の懸念事項です。

なんらかの理由で移行が失敗した場合は、すべてのステートメントをロールバックし、サイトをダウン状態にして、問題を解決しようとしている間、ユーザーがサイトを使用できないようにします。唯一のことは、移行ファイルがアセンブリでコンパイルされるため、データベースに対して手動でスクリプトを実行する方法にフォールバックできないことです。移行ファイルと sql スクリプト ファイルの両方を別々に追跡できましたが、その時点で移行を使用する理由はまったくありません。

職場では、スクリプト ファイルはサイトの (誰も参照できない) SQL フォルダーに格納されます。以前に実行されたスクリプト ファイルがデータベースに登録されます。新しいスクリプト ファイルがフォルダーに表示される (データベースには存在しない) 場合、ユーザーが管理者である場合は DB ポータルにリダイレクトされ、それ以外の場合はメンテナンスのためにサイトがダウンします。ポータルからスクリプトを実行しようとして失敗した場合は、新しいスクリプトを取得して Express Studio 内で手動で実行しようとします。これは10年以上にわたって機能しています。より良い方法が到着したかどうかを確認するために、移行を調査しているだけです。それはそれのように感じません。より良い方法があれば教えてください。それが移行ではない場合、それは何ですか。

SqlCeException ... The column cannot contain null values. [ Column name = Subtotal 次のEntityFrameworkの移行を実行すると取得します。

これはデフォルト値を設定する正しい方法ですか？簡単すぎるようです:)

レール上のルビーについて同様の質問を見た後、これを試しました。

検索しましたが、このトピックについてはあまり見つかりませんでした。インスタンス化、検証、保存などを含む、DBContext の簡潔な「操作の順序」を見た人はいますか? EF 4.3 Code First コンテキストで LINQPad を使用しているときに、自分のクエリの前に 2 つのクエリが実行されるため、主に興味があります。EF 移行を使用していて、自動更新が必要かどうかを確認しようとしているため、私が理解している移行履歴に関係するものと、EdmMetadata テーブルに関係するものがあります。 EFMigrations を使用している場合は必要ありません。

1つのクエリが呼び出される理由を理解していないため、理解/オーバーライドするのに役立つ可能性があることに気付いていないDBContextのライフサイクルの他の部分があるかどうか疑問に思います。前もって感謝します！

開発中は、Entity Framework 4.3 Migrations のようなフレームワーク (ただし、Migration クラスではなく SQL スクリプトを操作する必要があります) を使用して、すべての開発者データベースを最新の状態に保つというアイデアが気に入っています。誰かが最新のソースを取得するために更新を行い、アプリケーションを実行しようとすると、データベースを最新の移行に更新する必要がある (または移行を自動的に行う) 必要があるというエラーが表示されます。移行ファイルにはタイムスタンプが付けられるため、開発者は 2 つのファイルに同じ名前を付けたり、ファイルを実行する順序を気にする必要がありません。

WebDeploy 展開パッケージをビルドする準備ができたら、運用データベースを最新の db バージョンに移行するために必要なスクリプトをパッケージに含めたいと思います。したがって、MSBuild または WebDeploy は、どのスクリプトをパッケージ化する必要があるかを決定する必要があります。デプロイの場合、EF が提供するようなアプリケーション自体の更新を試みたくありません。パッケージを IT 部門に渡すか、展開サーバーを介して自動展開したいと考えています。

私の質問のいくつかは次のとおりです。

1. EF 4.3 は、開発のニーズに応じて DBMigration クラスの代わりに SQL スクリプトを使用できますか?

2. MSBuild または WebDeploy はデータベースの移行の概念を理解していますか (たとえば、EF. 4.3 migrationHistory テーブルを認識しますか)、それとも、prod データベースを最新の移行に移行するために実行する必要があるスクリプトだけを提供する必要がありますか? どのスクリプトをパッケージ化する必要があるかを手動で決定することは、私がやりたいことではありません。移行を理解する MS WebDeploy 拡張機能はありますか?

3. 私の懸念やアイデアは有効ですか？この辺は調べているだけなのでよくわかりません。

だから私はなんとかCodeFirstを実行することができ、それはうまく機能します。

私はまだアプリケーションを開発しているので、データベースの構造が完成していないので、移行を実装する必要があります。

私は公式ブログ投稿に従い、そのUpdate-Databaseコマンドを機能させました。

ただし、これはデータベースのSQLExpressバージョンのみを更新します。データベースの本番バージョンはAzure上にあり、実行時に接続文字列を指定するため、Update-Databaseコマンドはその上では機能しません。

最後の質問は、実行時に接続文字列が指定されている本番データベースに自動移行を適用するにはどうすればよいですか？

これまでコードファースト移行ベータ版を使用してきましたが、パッケージマネージャーコンソールを使用してデータベースを移行するときに-TargetDatabase、移行を適用するデータベースを指定することができました。たとえば、次のようになります。

移行がEntityFramework4.3に含まれるようになったため、EF 4.3を使用するようにアプリケーションを更新しましたが、-TargetDatabaseフラグを設定できなくなりました。パッケージマネージャーコンソールで実行すると、次のエラーが発生します。

EF 4.3での移行に関するブログ投稿を読みましたが、それに関する情報が見つかりません。また、古いSOの質問に対するコメントに気づきました。フラグは-Targetの代わりにすべき-TargetDatabaseですが、それも機能していないようです。フラグは、-Target移行先の移行を指定するために使用されているようです。

-TargetDatabaseフラグの名前が変更されましたか、または移行を適用するデータベースを指定するにはどうすればよいですか？

私は、ASP.NET Entity Framework 4.3 Code-First アプリケーションに取り組んできました。このアプリケーションは、データベースの重要な部分のモデルを管理します。このデータベースは他の複数のアプリケーション (一部は ef を使用していないため、モデルをインポートできない) で使用されるため、私のアプリケーションでベース データベースを作成するというアイデアがありました。この後、DBA は必要に応じてアプリケーションで使用されていない他のフィールドとテーブルを追加できます。

アプリケーションでモデルに変更を実装すると、問題が発生します。私たちのアイデアは、EF 4.3 の新しい移行機能を使用してスクリプトを作成し (-script 機能)、ローカル マシンの開発データベース (SQLCompact) を指し、実際の開発データベース (MS SQL 2008 ) 他のすべてのアプリケーションが使用します。

ただし、テストを開始したとき（SQLサーバーを指している）、アプリケーションが外部キー関係を読み取ることができず、これらの列が存在しないというエラーが発生したため、問題が発生していました。これは、SQL Compact と SQL Server の変換 (EF から SQL) の違いが原因なのか、それとも他の問題が原因なのか疑問に思っています。

このような 1 DB の複数アプリ環境で EF の移行を行う必要はありますか? すべての移行を SQL Server に対して直接実行する必要がありますか? 使用すべきまったく異なる変更戦略はありますか? ヘルプやガイダンスをいただければ幸いです。