I submitted a tiny patch to ActiveRecord's AssociationCollection#add_record_to_target_with_callbacks to fix what I believe to be a bug in the way that AssociationCollection#<< behaves if the :uniq option is set on its reflection.
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. Since :uniq only causes filtering of the result set in find_target, this means that we end up with unexpected results in our collection if we access it after we push duplicate records in, until the collection gets reloaded:
Given a class, Contact, that has_and_belongs_to_many :tickets with :uniq => true, for instance:
c = Contact.find(1)
=> #<Contact id: 1, ...>
c.tickets
=> [#<Ticket id: 1, ...>, #<Ticket id: 2, ...>, ...]
c.tickets.size
=> 6
c.tickets << Ticket.find(1)
=> [#<Ticket id: 1, ...>, #<Ticket id: 2, ...>, ...]
c.tickets.size
=> 7
c = Contact.find(1)
=> #<Contact id: 1, ...>
c.tickets.size
=> 6
Anyway, the really simple fix is at #738 Fixed AssociationCollection#<< resulting in unexpected values in @target when :uniq => true - Ruby on Rails - rails -- a few sets of eyes on it would be helpful.
Thanks!
