[Rails] Re: rescuing ActiveRecord::RecordNotUnique: clever or ugly?
Fearless Fool wrote in post #1053062:
> Peter Vandenabeele wrote in post #1052874:
>> A custom validation on the compound unique key would behave
>> similar, always do a SELECT (and suffer from the race condition
>> documented in
>>
>
http://api.rubyonrails.org/classes/ActiveRecord/Validations/ClassMethods.html#method-i-validates_uniqueness_of
>> ).
>
> I was aware of the race condition in the original post, which is why I
> thought this might be a 'clever' implementation. To merge what @Peter
> said, I guess you can summarize it as:
>
> If the likelihood of duplicate entries is low, let the db raise an error
> -- this saves a SELECT call for non-duplicate entries:
>
> def self.create_relation(src, dst)
> create!(:src_id => src.id, :dst_id => dst.id)
> rescue ActiveRecord::RecordNotUnique
> where(:src_id => src.id, :dst_id => dst.id)
> end
>
> If the likelihood of duplicate entries is high, use first_or_create as a
> first line of defense. This generates an extra SELECT, but (presumably)
> that's cheaper than frequent calls to raise/rescue[*].
A SQL query takes around 1 ms, possibly more if the db server is on a
different machine. That is way more expensive than rescuing an
exception.
Joe
> Regardless, keep
> the rescue clause to avoid race conditions:
>
> def self.create_relation(src, dst)
> where(:src_id => src.id, :dst_id => dst.id).first_or_create!
> rescue ActiveRecord::RecordNotUnique
> where(:src_id => src.id, :dst_id => dst.id)
> end
>
> [*] This begs for a benchmarking test to compare the cost of a SELECT vs
> raise/rescue. I'll put it on the list.
--
Posted via http://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home