Forum: Ruby on Rails ActiveRecord Comparison Bug?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ec76dc61f20bd5959c8a51b924d88851?d=identicon&s=25 Moo (Guest)
on 2009-04-09 08:58
(Received via mailing list)
Hi Everyone,

I'm running into a problem with the ActiveRecord::Base "==" method
defined here (it's 2.3.2, but it looks the same in older versions
too):

      # File rails-2.3.2/activerecord/lib/active_record/base.rb, line
2816
2816:       def ==(comparison_object)
2817:         comparison_object.equal?(self) ||
2818:           (comparison_object.instance_of?(self.class) &&
2819:             comparison_object.id == id &&
2820:             !comparison_object.new_record?)
2821:       end

Because of the last criteria (!comparison_object.new_record?),
something like this happens... say i have a new record and an existing
record (different objects) and compare them:

> new == old
=> true
> old == new
=> false

If this is intentional, can someone please explain why this is?

Also what is the rational of only comparing the ID and not the all the
values too and why does it matter if it's a new record or not?

Thank you!
-Moo
Ec76dc61f20bd5959c8a51b924d88851?d=identicon&s=25 Moo (Guest)
on 2009-04-10 18:51
(Received via mailing list)
Anyone has any thoughts on this please?
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2009-04-10 19:53
(Received via mailing list)
On Apr 10, 5:50 pm, Moo <janec...@gmail.com> wrote:
> Anyone has any thoughts on this please?
>
Basically the rationale is that == should mean 'do these objects
correspond to the same database row ?'

The reason why unsaved records are special cased is that two unsaved
record would have equal id (nil in both cases) but if you saved them
you would end up with 2 distinct rows in your database.

I'm not sure why you're getting  new ==old not being the same as old
== new. They should both be false (and are on my machine)

Fred
Ec76dc61f20bd5959c8a51b924d88851?d=identicon&s=25 Moo (Guest)
on 2009-04-16 02:38
(Received via mailing list)
Hi Fred,

Thank you for the response! What you said made sense. thanks for the
explanation.

However, looking at the last criteria of the == implementation, we can
see why something like what i mentioned would fail:

let's say i have an 2 AR objects:
> old = Something.find(1)
=> #<Something id: 1>

then i create a new object:
> new = Something.new
=> #<Something id: nil>
> new.id = 1 # something like this is possible, how or why is another story...
> new
=> #<Something id: 1>

now do:
> new == old
=> true
> old == new
=> false

== method should be commutative, right?

appreciate any comments!
-Moo

On Apr 10, 10:52 am, Frederick Cheung <frederick.che...@gmail.com>
2505b282d57c29be797dc35b245adb4c?d=identicon&s=25 Philip Hallstrom (Guest)
on 2009-04-16 05:18
(Received via mailing list)
> => #<Something id: 1>
>> new == old
> => true
>> old == new
> => false
>
> == method should be commutative, right?

You've got something screwy somewhere...

old = Toy.fin>> old = Toy.find(1)
=> #<BabyToy id: 1, ......>
 >> new = Toy.new
=> #<Toy id: nil, ....>
 >> new.id = 1
=> 1
 >> old == new
=> false
 >> new == old
=> false

Rails 2.3.2.1

-philip
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2009-04-16 09:55
(Received via mailing list)
On Apr 16, 4:17 am, Philip Hallstrom <phi...@pjkh.com> wrote:
>
> You've got something screwy somewhere...
>
Your case is different because of STI (so your comparisons here are
all false because the objects are of different class). If it weren't
for that then it's a slightly messed up situation - Active record
thinks it has a new record but it doesn't

Fred
2505b282d57c29be797dc35b245adb4c?d=identicon&s=25 Philip Hallstrom (Guest)
on 2009-04-16 19:12
(Received via mailing list)
> Your case is different because of STI (so your comparisons here are
> all false because the objects are of different class). If it weren't
> for that then it's a slightly messed up situation - Active record
> thinks it has a new record but it doesn't

Doh!  Didn't catch that.  And when I do it without involving STI then
I get the results he's getting below.  Sorry Moo!

Hrm... well down in AR::Base we have this:

       # Returns true if the +comparison_object+ is the same object,
or is of the same type and has the same id.
       def ==(comparison_object)
         comparison_object.equal?(self) ||
           (comparison_object.instance_of?(self.class) &&
             comparison_object.id == id &&
             !comparison_object.new_record?)
       end

Which interestingly enough matches each of the conditions the parent
posted about.

I guess what this means then is if you're mucking around setting the
id's of a record and before they are saved you should call equal?
directly.

 >> old = AdminUser.find(1)
=> #<AdminUser id: 1...>
 >> new = AdminUser.new
=> #<AdminUser id: nil...>
 >> new.id = 1
=> 1
 >> old == new
=> false
 >> new == old
=> true
 >> old.equal?(new)
=> false
 >> new.equal?(old)
=> false
This topic is locked and can not be replied to.