Rails 3.2アプリをレガシーデータベースに構築していますが、これには別のテーブルにもいくつかの壊れたレコードがあります。最も頭を悩ます問題の 1 つは、無効な日付が含まれていることです。
コードを機能させるために一度手動で修正したサンドボックスをセットアップしました。いよいよ導入です。このため、サンドボックスは毎晩リセットされ、ライブ データベースからコピーされ、ferret インデックスが再構築され、移行が再適用されます。ライブ セットアップにデプロイする前に、最終的な修正を取得するためにサンドボックスに頻繁にデプロイします。
レガシーPHPアプリとこの新しいRailsアプリは、数週間から数か月間並行して実行する必要があるため、日付を1回だけ修正することはできません（更新：明確にするために、同じデータベースで同時に実行することを意味します時間）。おそらく移行またはレーキタスクを使用して、これを自動化する方法が必要です（私は後者を選びます）。
しかし、問題は、ActiveRecord がそのようなレコードをロードするときにチョークするため、Ruby コードでハードコーディングされた仮定によってレコードを調査して日付を修正する方法がないことです。
2 つ目の問題は、PHP コードがトランザクションを使用せず、一部のコード パスが壊れており、孤児や壊れたテーブル制約が残っているため、レガシー データベースに矛盾があることです。それらが発生したときに対処しますが、それらのほとんどはモデルで既に処理されています。最初の問題は日付です。
通常、これをどのように修正しますか？例外をインターセプトし、修正を試行するコードを実行することで、壊れたレコードを含むレガシー データベースの移行をサポートする魔法の宝石さえあるかもしれません...
移行パスでは、MySQL と 3 つの実稼働環境 (ライブ データベースを使用する安定、同じデータベースを使用するステージング、毎晩データベース クローンをリセットするサンドボックス) を使用します。完全なレガシー アプリケーションを 1 ステップで置き換えることはできないため、1 回限りのデータ マッピング/移行は行わないことにしました (約 50,000 の記事、数百のトピック、画像とダウンロードを含む巨大なファイル データベース、約 10 の Web サイトをサポートする CMS で構成されます)。 、約 12 年間のデータと作業、さまざまなプログラミング スキルによる乱雑な PHP コード、さまざまな移行段階からのコードの複製、パートナー サイトから RSS コンテンツを取得して、そこからの記事/投稿を独自のアプリケーションのトピックの記事タイムラインに混ぜ合わせます。もっと楽しいことたくさん…
最初のステップは、バックエンド アプリケーションを移行して、一貫した管理および発行インターフェイスを取得することです。従来のフロントエンド アプリケーションは、データベースに書き込む必要があります (訪問者が作成したコメントやその他のコンテンツ)。したがって、データベースを修正するプロセスは、定期的に無人で実行できる必要があります。
私たちは、begs_to と has_many で破損したモデルの依存関係を適切に処理するための修正を既に実施しています。Paperclip の統合は、発明されたすべての素晴らしいファイル名マッピングと連携するように設計されています。また、airbrake gem は、すべてのアプリケーションのクラッシュを Redmine インストールに報告するので、残っているすべての癖の概要をすばやく把握できます。
レガシー アプリケーションは、最新の MySQL バージョンで動作するように既に変更されており、現在の MySQL データベース サーバーに移行されています。