POLA http://en.wikipedia.org/wiki/Principle_of_least_astonishment
Examples
```
# user.rb
class User ActiveRecord::Base
attr_accessible :name, :username
validates :username, uniqueness: true
end
user1 = User.create(name: 'Name 1', username: 'username1')
user2 = User.create(name: 'Name 2',
# update_attribute is expected to update the specified attribute, not
other ones. Thus it is violating POLA
This is why you never want to rely on validates_uniqueness_of. It's
essentially a convenience for generating pretty error messages. Use your
DB's unique constraints to validate
On Mar 12, 2014, at 7:23 AM, Anh Nguyen khac...@gmail.com wrote:
POLA http://en.wikipedia.org/wiki/Principle_of_least_astonishment
Examples
```
# user.rb
class User ActiveRecord::Base
attr_accessible :name, :username
validates :username, uniqueness: true
end
user1 =
On 12-03-2014 08:23, Anh Nguyen wrote:
POLA http://en.wikipedia.org/wiki/Principle_of_least_astonishment
Examples
```
# user.rb
class User ActiveRecord::Base
attr_accessible :name, :username
validates :username, uniqueness: true
end
user1 = User.create(name: 'Name 1', username:
The issue here does not seem to be what everyone is addressing. If I
understood Anh correctly, when you run update_attribute X on a unsaved
model that has one attribute Y set in memory, calling reload will report
both X and Y as saved, so it seems to be a reload issue at first glance. I
will try
The point is that dirty attributes get persisted, not just the one you set.
That is, the (invalid) username was saved because validations are skipped
and the model as such is saved.
Persisting dirty attributes is not an overlook, callbacks are run so you
need to take the model as a whole and
True. I somehow overlooked the fact that update_attribute saves dirty
attributes. Xavier, you said the purpose of update_attribute was to save
quick stuff, are there plans to deprecate this behavior?
On Wed, Mar 12, 2014 at 4:10 PM, Xavier Noria f...@hashref.com wrote:
The point is that dirty
Yeah, but it's kinda misleading that update_attribute saved other
attributes and not just the one specified in the argument, being that the
method is update_attribute as a singular attribute. The reload works
fine, as the username was saved with update_attribute, which saved more
than what it was
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
On Wed, Mar 12, 2014 at 4:21 PM, Mohamed Wael Khobalatte
wael.khobala...@gmail.com wrote:
True. I somehow overlooked the fact that update_attribute saves dirty
attributes. Xavier, you said the purpose of update_attribute was to save
quick stuff, are there plans to deprecate this behavior?
It
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
11 matches
Mail list logo