This project is archived and is in readonly mode.
Fixed AssociationCollection#<< resulting in unexpected values in @target when :uniq => true
Reported by Ernie Miller | August 2nd, 2008 @ 04:49 PM | in 2.x
When AssociationCollection#<< is called, it invokes #add_record_to_target_with_callbacks, which doesn't pay any attention to the reflection's :uniq option before pushing to the @target array, and can result in unexpected values showing up in @target until @target is reloaded. This patch resolves this issue.
Comments and changes to this ticket
-
wildchild August 7th, 2008 @ 04:24 AM
- Tag changed from activerecord, enhancement, patch to activerecord, bug, patch
+1 for this feature. Should we fire callbacks for already duplicate records?
In patch:
@target << record unless @reflection.options[:uniq] && @target.include?(record) callback(:after_add, record)
Why not:
unless @target.include?(record) @target << record unless @reflection.options[:uniq] callback(:after_add, record) end
Cheers.
-
Ernie Miller August 7th, 2008 @ 11:46 AM
I debated about that. In the end, since ActiveRecord doesn't actually prevent duplicate records in the DB, but only in the @target array, when :uniq is set, I felt it would be presumptuous to mess with callbacks. There could be a very legitimate bit of data massaging going on there.
-
Michael Koziarski August 8th, 2008 @ 01:50 PM
- Assigned user set to Michael Koziarski
Shouldn't it raise an exception if you try to do this? Silently ignoring the call seems like a potential cause of lots of bugs.
-
Michael Koziarski August 8th, 2008 @ 02:19 PM
- State changed from new to resolved
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>