2

いくつかのモデルがすべてメモリ内でリンクされており (親:子:子:子)、最上位の親を保存することで同時に保存されています。これはうまくいきます。

子の 1 人の after_create コールバックを利用して、変更ログ テーブルに入力したいと思います。changelog テーブルにコピー/プッシュする必要がある属性の 1 つは、直接の親に対する子のforeign_key ですが、after_create が起動した時点では存在しません!?!

after_create コールバックがなければ、ログを調べて、子が親の前に保存されていること (外部キーが空白) を確認できます。その後、親が挿入されます...その後、子は親からの IDで更新されます。子の after_create は適切なタイミングで起動していますが、Rails が子をforeign_keyで更新する前に発生しています。

このようなモデルのリンクを特定の順序で強制的に保存する方法はありますか? つまり、親、子 (親のforeign_keyが存在する)、その子の子(再びforeign_keyにアクセス可能)などです。そうでない場合、レコードが作成された後にルーチンを起動し、foreign_key を取得するにはどうすればよいでしょうか?

次のようなコールバックが役立つようです: after_create_with_foreign_keys

4

2 に答える 2

2

関連するすべてのモデルをメモリ内に構築し、最上位の親を保存するときにすべてを保存するために Rails に依存していたため、 after_create コールバックを利用して外部キーを (change_log テーブル エントリ用に) 利用することができませんでした。 Railsがモデルを保存する順序。すべてが常に適切な方法で接続されましたが、子レコードが最初に保存され、次に親が保存され、次にparent_idを挿入するために子レコードが更新されることがありました。

私の解決策は、モデルをメモリ内に構築せず、すべてを一気に保存するという考えを放棄することでした。代わりに、最上位のモデルを保存してから、その親の after_create を介してその子を作成します。その子の after_create は、その子を作成します。外部キーに関連するコールバックをより詳細に制御できるため、この配置の方がはるかに気に入っています。最後に、途中で何かひどく問題が発生した場合に挿入を元に戻すために、すべてが db トランザクションにラップされました。これが、すべてをメモリ内に構築する最初の理由だったので、保存する前にすべてのアヒルを一列に並べました。モデル/データベース トランザクションはその心配を軽減します。

于 2010-05-02T21:51:55.027 に答える
0

after_updateparent_id が利用可能になった後、子をキャッチするために使用できますか? 発火するafter_updateと、parent_id が使用可能になるので、子がテーブルにない場合は挿入します。

于 2010-03-12T17:47:34.773 に答える