You should have the database constraint even if update_attribute worked
exactly the way you thought it would. It's even stated in the
documentation for validates_uniqueness_of:
http://api.rubyonrails.org/classes/ActiveRecord/Validations/ClassMethods.html#method-i-validates_uniqueness_of
See "Concurrency and integrity". Unless your application is not
multi-thread and has a single worker process, but I don't think this is
the case, right? ;)
Best,
Rodrigo.
On 12-03-2014 12:30, Anh Nguyen wrote:
Sorry, it should be
user1.update_attribute(:name, 'New Name')
I switched to update_column but the old code already created some
dirty records in the DB. I should have created validation at DB level
instead of trusted AR completely.
On Wednesday, March 12, 2014 7:27:41 PM UTC+7, Xavier Noria wrote:
update_attribute and update_attributes do this:
1) They update the passed attributes in the receiver.
2) They save the receiver.
The arguments say which attributes have to be updated, and as a
convenience the model is saved (callbacks run, timestamps are
updated, etc.).
In addition, update_attribute has some extra semantics, in
particular validations are skipped and that's why it succeeded in
your example. (Was the example written by hand? the call does not
seem to be valid.)
In recent version of Rails you can use update_column(s), whose
semantics are less confusing than the ones of update_attribute.
But it is also going to skip validations and other AR stuff
because it issues straight SQL.
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
