問題タブ [fluent-migrator]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
fluent-migrator - カラムのデフォルトを SQL Server の NewId() に設定することは可能ですか?
fluentMigrator で、列のデフォルトを関数に設定することは可能ですか?
具体的には、既にデータが含まれている SQL Server 2008 テーブルに uniqueidentifier (Guid) 列を追加しています。これは必須フィールドになります。NewId() 関数に既定値を設定することはできますか?
c# - application_startで流暢な移行を使用することは可能ですか?
私は流暢な移行ツールを使用してデータベースの移行を管理していますが、私がやりたいのは、アプリの起動時に移行を実行することです。私が管理した最も近いものはこれです:
私はこれが機能していたと確信していますが、しばらくは見ていませんでした(趣味のプロジェクト)。現在、Execute
行に到達するとnull参照例外がスローされます。悲しいことに、これに関するドキュメントはなく、私は何年もの間それに頭をぶつけてきました。
誰かがこの種のものをFluentMigratorで動作させることができましたか?
fluent-migrator - カスケード削除ルールを移行に追加できますか?
FluentMigratorの移行で、関係を定義している場合は、次のように言います。
それらの間のカスケード削除タイプの関係を定義する方法はありますか?たとえば、MainTableから何かを削除すると、関連するレコードも削除されますか?
.net - FluentMigrator.Runner は 32 ビット アセンブリを出力ディレクトリにコピーします
FluentMigrator.Runner を参照する移行プロジェクトがあります。このアセンブリは、System.Data.SQLite.dll の 32 ビット バージョンを参照します。したがって、このプロジェクトを 64 ビット サーバーにデプロイすると、例外が発生します。
不正な形式のプログラムをロードしようとしました。
ソリューション内のすべての System.Data.SQLite.dll を削除すると、SQLite も必要ありません。すべて正常に動作します。しかし、これを解決するためのより良い方法を探しています... FluentMigrator が更新された場合、この 32 ビット アセンブリが再び使用されるためです。
この間接参照アセンブリを出力ディレクトリにコピーしないように Visual Studio に指示する方法はありますか? または、不要な dll をすべて削除するよりも良い解決策はありますか?
編集: FluentMigrator (1.0.1.0) の最新の Nuget パッケージを使用しています
Edit2: FluentMigrator-Package の FluentMigrator.Runner.dll も 32 ビットのみであるため、FluentMigrator.Tools NuGet-Package の FluentMigrator.Runner.dll の AnyCPU バージョンを参照しています。しかし、私の問題は、32 ビット版の System.Data.SQLite.dll です。FluentMigrator.Tools パッケージの AnyCPU フォルダに別の System.Data.SQLite.dll がありますが、この DLL は 32bit 版と同等のバイナリです (なぜ??)...
c# - Fluent Migrator で以前のバージョンにロールバックする
流暢な移行ツールを使用して、自分のプロジェクトで移行を機能させようとしています。しかし、ドキュメントが不足しているため、ロールバックしDown
て移行クラスに対してメソッドを呼び出す方法を理解するのに苦労しています。
最初のバージョン 1 クラスを使用してデータベースをセットアップしました。
以下を含むバッチファイルを介して移行を実行しています。
"....\tools\fluentmigrator\migrate.exe" --connection "データ ソース=.\sqlexpress;初期カタログ=ekmDomains;統合セキュリティ=true;multipleactiveresultsets=true;" --db SqlServer2005 --target "bin\Release\EkmDomains.Migrations.dll"
これはうまくいきます。そこで、テストするためだけに 2 つ目の移行クラスを作成しました。
再びバッチ ファイルを実行すると、すべて正常に動作します。次に、流暢な移行ツールのコマンド ライン オプションを調べたところ、オプションが見つかりました--version
。以前のバージョンにロールバックするには、単に指定するだけで of が呼び出されると想定し--version 1
ましDown
たAddNewTable
。しかし、それは起こりませんでした。コンソールは単に「committing transaction」メソッドを表示して閉じます。ただし、テーブルは削除されておらず、バージョン番号も変更されていません。
私はこれを間違った方法で行っていますか、それとも私がこれを行っている方法に根本的な欠陥があると誰かが見ることができますか?
version-control - バージョン管理下で大規模なレガシー データベースを取得する方法
データベースのバージョン管理がない、継承された大規模なレガシー プロジェクトがあります。流暢な移行を作成し、ソース管理下に置いて、将来これを管理したいと考えています。
私の問題は、プロジェクトが大規模であることです。6 つの個別のデータベースが含まれています。各データベースには、多くのビジネス ロジックが含まれています。~120,000 のストアド プロシージャ、トリガー、ビュー。これは手作業で行うには多すぎます。
空のデータベースから本番環境のスナップショットへの流暢な移行を生成する方法はありますか?
c# - FluentMigrator でコードとステータス値を追加するためのベスト プラクティスは?
Entity Framework 4 (コードファースト) と Fluent Migrator を使用するプロジェクトに取り組んでいます。
プロジェクト全体を通して、すべてのスキーマ変更の移行と、さまざまな環境に入力したいテスト データのプロファイルを作成しました。
ただし、すべての環境に入力する「コード」や「ステータス」を挿入するためのベスト プラクティスは何ですか? テーブルの作成時にそれらを指定する必要がありますか、それともテーブル用の特定のプロファイルを作成する必要がありますか?
より具体的には、次のように、データベース用に定義されたアドレス タイプの「コード」テーブルがあります。
では、この機会を利用して、AddressTypes テーブルにもデータを入力する必要があるでしょうか? それとも、それをある種のプロファイルに抽象化する必要がありますか?
どちらにもメリットとデメリットがあるので、他のチームがこの種の状況にどのように対処しているかを知りたいです。
.net - FluentMigratorでトリガーを作成することは可能ですか?
生のSQLに頼らずに、FluentMigratorでトリガーを作成することは可能ですか?
現在Nugetでリリースされているバージョン(FluentMigrator.1.0.1.0)のオブジェクトモデルを調べましたが、その方法がわかりません。
fluent-migrator - Fluent Migrator で一意の制約を定義する
Fluent Migrator を使用して一意の列を作成しようとしています。ただし、次のように、一意の制約を列定義と一緒に定義しようとすると機能しません。
次のように移行を実行します。
出力:
明らかに、一意のインデックスは作成されません。ただし、スタンドアロン コールでインデックスを作成すると、次のようになります。
出力:
これに関して github でいくつかの問題を見つけました (例: #49と#83 ) が、このプルを参照してクローズされました。
間違ったバージョンを使用しているのだろうか。NuGet から入手できるバージョン 1.0.1.0 を使用しています。
ここで私が間違っていることについてのヒントをいただければ幸いです。前もって感謝します!
よろしく、 アンドレ
database-migration - データベース バージョンの展開。Entity Framework の移行と SSDT DacPac の比較
SQL Server を使用したデータ中心のアプリケーションがあります。それが展開される環境は私たちの管理下になく、そこには DBA がいません (彼らはすべて中小企業です)。そのため、各アプリケーション/データベースの更新の配布プロセスを可能な限り自動化する必要があります。
アプリケーションのバージョン間の通常の変更 (予測できない場合があります) に加えて、各バージョンで新しいシード データを配布する必要があることは既にわかっています。このシード データは、システム内の他のデータに関連する場合があります。たとえば、v2 から v3 への更新プロセス中に一部のマスター データの 2 つの新しい行を挿入し、v5 から v6 への更新プロセス中に他の 5 行を挿入する必要があるかもしれません。
EF
Entity Framework Db Migrations (4.3.1 リリース以降の Code-First のない既存のデータベースで利用可能) を確認しました。これは、従来のシーケンシャル スクリプトをより自動化され制御された方法 (Fluent Migrations など) で表します。
SSDT
一方、別の考え方で、SSDT とその dacpacs、スナップショット、デプロイ前後のスクリプトを確認しました。
質問は次のとおりです。
これらの技術/哲学のうち、説明されているケースにより適切なものはどれですか?
他に使用できるテクノロジー/哲学はありますか?
他にアドバイスはありますか?
前もって感謝します。