0

モデルの特定のフォーム送信が2段階のプロセスであるRailsアプリがあります。最初の送信時に、Railsコントローラーはモーダル確認フォームのレンダリングを発行し、そこから更新アクションが呼び出されるか、すべてがキャンセルされます。

Rails の楽観的ロックは、古い更新に対処するための答えのようです。

ただし、ユーザー エクスペリエンスのために、Rails コントローラーがユーザー A のモデル バージョンを現在のバージョンと比較できる場合、モデルが既に古くなっているかどうかを判断する更新アクションを待たずに (ユーザー B が問題のモデルを同時に更新しているため)、次に、別の種類のビューをレンダリングして、更新されたモデルを調べる必要があることをユーザー A に示すことができます。

コントローラーの :lock_version フィールドを手動でチェックし、それを params[] バージョンと比較することに関連する問題や落とし穴はありますか? これを行うための組み込みまたは「正式な」方法はありますか、それともコントローラーが明示的にチェックを行う必要がありますか?

4

1 に答える 1

0

lock_version の主な問題は、それが 1 つのサイズですべてに適合すること (つまり、異なるコンテキストに対して異なるロックを設定できないこと) であり、ロックの失敗によって古いオブジェクトの例外がスローされることであり、これはユーザーにとって特に適切ではありません。

Ryan Singer は、updated_at タイムスタンプを検証と組み合わせて使用​​してチェックを実行し、次に Rails ダーティ トラッキングを使用してユーザーに何が変更されたかを示す別のアプローチを提示しました。Rails Cast で見ることができます: http://railscasts.com/episodes/59-optimistic-locking-revised

私はこの手法を使用しており、満足していますが、与えられた例は、複数のモデルがアクションに関与している、またはモデルの関連付けが変更されていないことを確認する必要があるなどのより複雑なケースをカバーしていません.

于 2013-07-15T00:38:04.300 に答える