.eql? @product.files
=> false
@product.files.eql?
=> true
version: 2.3.5 Product :has_many files
>> .eql? @product.files => false >> @product.files.eql?
You've uncovered Active Record's terrible secret, files isn't actually an Array.
Fred
You’ve uncovered Active Record’s terrible secret, files isn’t actually
an Array.
Actually I’d call it magic or voodoo, but not a dirty secret.
It’s actually a brilliant/necessary part of the arel features in Rails 3. When you select a recordset using Rails 3 arel features (where, order, etc), it doesn’t actually call the DB until you iterate over the resultset. This means if that part of the view is cached, it won’t actually hit your DB at all. If files was an array it would have had to call the DB to fill the array, only for it not to be used.
So, the OP’s code snippet is not surprising - @product.files is not an array, but if you use the eql? method on that object it will compare it’s internal data to an empty array (but arrays know nothing about this ActiveRecord class).
Cheers,
Andy
Yes, I know about this AR behavior. I think, would be correct if the comparison works both ways. For beginners, it looks like a bug.
Alexander G. wrote:
Yes, I know about this AR behavior. I think, would be correct if the comparison works both ways. For beginners, it looks like a bug.
Is it really worth monkeypatching Array#eql? for this? I think not.
Best,
Yes, I know about this AR behavior.
I think, would be correct if the comparison works both ways.
For beginners, it looks like a bug.
Is it really worth monkeypatching Array#eql? for this? I think not.
I almost posted the same thing earlier, but had a second thought.
Would it not be easier to create a to_a method on the ActiveRecord resultset object (whatever that is)?
It’s not going to be as efficient as it will then (at that point) need to instantiate all result objects to compare, but it would then work both ways round…
But I didn’t get a chance to look further in to it to test the theory/idea.
Cheers,
Andy
