2

古いRailsアプリケーションをRails3.2.11/Ruby1.9.3に移行しています。

別のモデルから継承するモデルActiveRecordがあります。ロードされると、を設定するメソッドを呼び出します。このためには、「イベントID」が必要です(各イベントには独自のデータベースがあります)。ControlPointEventDependentControlPointEventDependenttable_name

このすべての鍵は、モデルがロードされるときに「イベントID」を知る必要があるということです。

control_point_controllerは、before_filter(paramsを介して)必要な「イベントID」を取得するコントローラーメソッドを呼び出す必要があります。Railsの以前のバージョンでは、これは常に正常に機能していました。

しかし、Rails 3.2.11では、動作する場合と動作しない場合があります。

それが機能しない場合、問題は、「イベントID」の準備が整う前に、モデルの「テーブル名の設定」が呼び出されることです。デバッガーでデバッグしようとしましたが、その前に失敗するため、フローがbefore_filterアクションに入らないことがよくあります。それが入るときもあります...そしてそれが入るとき、私たちは利用可能なパラメータを持っています、そしてそれはすべてうまくいきます。

私はこれについて探していましたが、関連する特定のものを見つけることができませんでした。問題は、モデルとコントローラーのロード順序が固定されていないことです...そしてそれらは同時にロードを開始し、時には一方が他方の前にロードされることがあります。これは意味がありますか?「eventid」がまだ定義されていないため(before_filterが実行されておらず、paramsがまだ存在していないため)、約70%は機能しないと思いますが、残りの30%は機能します。

私の質問は:モデルのロードをどうにかして遅らせることができますか?または、コントローラーのbefore_filterの後にロードしますか?問題が何であるかについての他の考えはありますか?

必要に応じて、関連するコードを投稿できます。

4

1 に答える 1

1

私はこれに対する解決策を見つけ、誰かが同様の問題を抱えている場合、またはより良いアイデアを提案したい場合に備えて、それをあなたと共有したいと思いました。

私が言ったように、問題は、この呼び出しが次のようにモデル内で単に「フローティング」であったため、モデルで「set_table_name」が実行されるタイミングを制御できないことでした。

class ControlPoint < EventDependentModel
    set_table_name 'ControlPoints'
    ....
    ....
end

したがって、これがbefore_filterコントローラーの前に呼び出されたとき(ランダムに発生することがありました...)、「event_id」はまだ使用できませんでした。

私がしたことは、その呼び出しをset_table_nameモデルから削除し、次before_filtercontrol_point_controllerように別の呼び出しを追加することでした。

class ControlPointsController < EventDependentController
    before_filter :prepare_table_name
    .....
    .....

    protected
       def prepare_table_name
           ControlPoint.set_table_name 'ControlPoints'
       end
end

にもう1つありbefore_filterEventDependentController必要な「event_id」を(paramsを介して)設定します。このように、いつset_table_name実行されるか(コントローラーのすべてのアクションの前に)、「event_id」は親のもう一方のbefore_filterによってすでに設定されています。コントローラ。

よろしく!

于 2013-01-30T10:31:51.227 に答える