It seems that validates_uniqueness_of :some_field will run on a “save” even if the some_field attribute has not changed (if other fields have changed). This seems wasteful, since each validates_uniqueness_of will require a database call. I know I can pass a Proc to validates_uniqueness_of to check whether some_field has changed, and I am considering going through all the validations and doing that wherever possible. What I am wondering is:
1) Is that what people interested in performance generally do with their validations?
2) Why is it not validates_uniqueness_of’s default behavior to check whether the attribute has changed first?
3) Are there good reasons for running such validations on attributes that haven’t changed?
I am using Rails 2.3 (for the moment– we are working on upgrading). I don’t know this is the same situation in Rails 3.
What if someone changed the value in the database directly?
What if some other (non rails app) app also accesses the database?
In all above scenarios you will still want that your data be valid, so that your rails application behaves as expected. In case the data was tampered with (by the other app, or in database directly), your rails app throws an error because it doesn’t expect that data.
Having said that, it is the default behaviour. The default behaviour is generally more restrictive, in order to maintain data validity and minimise scope of errors, omissions, and occasional slips. In case you are worried about performance in your case, maybe your object is being updated very frequently, and you have a lengthy custom validation on a field that isn’t being updated that frequently, and you don’t want to run that validation each time, then it makes perfect sense to customize the default behaviour as you have described in the question.