[過去ﾛｸﾞ] 【本命】Blazor スレ1【真打】 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
700(1): 2020/11/08(日)12:42 ID:QCCK7Xg4(1/7) AAS
>>699
postgresqlは特殊な仕様だからハマりやすいね
なのでNpgsqlのEFにはUseSnakeCaseNamingConventionというオプションがある
他のDBは特にハマった記憶がない
704(1): 2020/11/08(日)13:08 ID:QCCK7Xg4(2/7) AAS
>>701
最近のEFは良くなってる
ほぼ想像どおりのスキーマを出力してくれる
とはいえ完璧とも言えない
完璧を求めるならMigrationを生SQLで手書きすることもできる
SQLを手書きしたいという要求のためにMigrationの全機能を手放すのは惜しい
706(1): 2020/11/08(日)13:15 ID:QCCK7Xg4(3/7) AAS
>>703
いやいやスキーマを変更したあとにテストじゃ遅いだろ
Migrationをしてからテストするんじゃない
テスト済のMigrationを適用するんだ
ちなみにMigrationはアプリケーションをデプロイするだけなので手順ミスは最小化される
手作業でSQLを実行するとSQL数に比例してミスが増える
709: 2020/11/08(日)13:33 ID:QCCK7Xg4(4/7) AAS
>>707
EFモデルファーストは文字列の長さなど細かいコントロールも当然可能だ
より詳細な調整をしたい場合はMigrationを手書きしてMigrationBuilderに生えてるDDLラッパーを呼び出せば良い
DDLラッパーはCreateTableメソッド、DropTableメソッドなど.NETのメソッドではあるがDLLを書くのと非常に近い感覚で使うことができる
これはラッパーなので複数ベンダに対応することができる
代わりに最大公約数的な機能に制限されるが十分な機能揃っている
完全にMigrationをコントロールしたい場合には生のSQLを書いてもいい
EFはもちろん生のSQLもサポートしている
原始時代や産業革命時代に行っていたような作業はすべてEFでできる
ただし生のSQLを使うとベンダ依存が発生するのでそこはトレードオフだ
省3
710: 2020/11/08(日)13:34 ID:QCCK7Xg4(5/7) AAS
手作業でSQLを実行するだけではこのような複雑なMigrationには対応できない
711: 2020/11/08(日)13:38 ID:QCCK7Xg4(6/7) AAS
>>708
決定事項だろうがなんだろうがテストは必要だ
これからDBに対して行う変更を事前にテストする
テスト済の変更を確実にミスなく適用する
これを実行するための最もスマートな方法がMigrationだ
先程も書いたがこれをオレオレshellで代用することはできる
しかしそれは洗練された手法ではない
産業革命時代のやり方でしかない
もちろん適用したあとに最終チェックとしてテストを行うことはこちらとしても全く否定していない
713: 2020/11/08(日)13:47 ID:QCCK7Xg4(7/7) AAS
なおMigrationとその後のテストのどちらかが失敗した場合は
途中まで適用したMigrationをロールバックしなければならない
ロールバックはEFの機能で行うかDBバックアップをリストアするかどちらかだが
EFの機能で実施したほうが圧倒的に速い
リストアは最後の手段と考えよう
バグを放置してアプリケーションコードを修整するなどもってのほかである
これはサービスの停止時間を悪戯に伸ばすだけで損失を増やすばかりでなんの利益も産まない
バグがあったらロールバックを行い
Migrationとアプリケーション双方を見直し修整しテストする
テストした後にまたMigrationを適用する
省1
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s