6

some_field 属性が変更されていない場合でも (他のフィールドが変更されている場合)、 validates_uniqueness_of :some_field が「保存」時に実行されるようです。validates_uniqueness_of ごとにデータベース呼び出しが必要になるため、これは無駄に思えます。Proc を validates_uniqueness_of に渡して some_field が変更されたかどうかを確認できることはわかっています。すべての検証を実行し、可能な限りそれを行うことを検討しています。私が疑問に思っているのは：

1) それは、パフォーマンスに関心のある人々が一般的に検証で行うことですか?

2)属性が最初に変更されたかどうかを確認するvalidates_uniqueness_ofのデフォルトの動作ではないのはなぜですか?

3) 変更されていない属性に対してそのような検証を実行する正当な理由はありますか?

私は Rails 2.3 を使用しています (現時点では、アップグレードに取り組んでいます)。これがRails 3でも同じ状況かどうかはわかりません。

4

2 に答える 2

4

誰かがデータベースの値を直接変更した場合はどうなりますか？

他の（Rails以外のアプリ）アプリもデータベースにアクセスした場合はどうなりますか？

上記のすべてのシナリオで、Railsアプリケーションが期待どおりに動作するように、データが有効である必要があります。データが（他のアプリによって、またはデータベース内で直接）改ざんされた場合、Railsアプリはそのデータを予期しないため、エラーをスローします。

そうは言っても、これがデフォルトの動作です。データの有効性を維持し、エラー、脱落、および時折発生するスリップの範囲を最小限に抑えるために、デフォルトの動作は一般により制限されています。ケースのパフォーマンスが心配な場合は、オブジェクトが非常に頻繁に更新されており、それほど頻繁に更新されていないフィールドに対して長いカスタム検証があり、それぞれの検証を実行したくない場合があります時間があれば、質問で説明したようにデフォルトの動作をカスタマイズすることは完全に理にかなっています。

于 2012-05-01T21:01:49.477 に答える