Bug in Rails 2.0 when overloading a find_by method?

As suggested in my thread in Ruby On Rails: Talk (http:// groups.google.com/group/rubyonrails-talk/browse_thread/thread/ 66ae64e6581a3896) i'm posting an issue i'm having with Rails 2.0 and overloading find_by methods here. Hoepfully someone can either suggest what I am doing wrong and should be doing instead to get this working, or tell me where to submit a bug report so this can get fixed if it is not desired behaviour:

This came up when I migrated from rails 1.2.3 to 2.0.2. Previously, my code was working fine. I am using a mysql backend database, in which I am storing IPv4 addresses as 32 bit unsigned integers. Of course, I don't want my users to have to enter the IP they are searching for in this fashion, nor do I want to have to make the conversion myself every time I call the find_by_ip function or find_or_create_by_ip function for the model, so I have overloaded those two functions. find_by_ip now reads as follows:

def self.find_by_ip(ip)   super(NetAddr::CIDR.create(ip).to_i) end

This works, the first time Ip.find_by_ip(address) is called (this test done in script/console):

ip = Ip.find_by_ip("10.21.1.8")

=> #<Ip id: 13, ip: 169148680>

However any subsequent calls to find_by_ip just return nil, even for the same IP address, until the environment is reloaded:

reload!

Reloading... => true

ip = Ip.find_by_ip("10.21.1.8")

=> #<Ip id: 13, ip: 169148680>

ip = Ip.find_by_ip("10.21.1.8")

=> nil

If I add some puts statements in my overloaded find_by_ip, they never get printed out after the first call to it has been done. Equally, if I call find_by_ip with a 32 bit int form of an IPv4 address it works reliably:

def self.find_by_ip(ip)   puts "Testing\n"   super(NetAddr::CIDR.create(ip).to_i) end

?> reload! Reloading... => true

ip = Ip.find_by_ip("10.21.1.8")

Testing => #<Ip id: 13, ip: 169148680>

ip = Ip.find_by_ip("10.21.1.8")

=> nil

ip = Ip.find_by_ip(169148680)

=> #<Ip id: 13, ip: 169148680>

It is as if, after the first call to my overloaded find_by_ip, rails decides to ignore my overloaded function and go straight to the base functionality it has for creating find_by functions. The suggestion was that, in Rails 2.0, instead of calling the method_missing function every time I call super() from within a find_by_function (as there is no specific find_by function of that name in ActiveRecord::Base), it instead creates the find_by_ip function, which overwrites my one, and subsequent calls hit that and thus don't get the IP address converted to an int, and thus don't find any matching record in the database. I am assuming this change was made for speed, as as long as you are not overloading a find_by function it will be faster if the function is pre-generated instead of having to be created every time it is called, but what can I do to fix this? Is the best fix to call my 'overload' function get_by_ip (or similar), so that the created find_by_ip function doesn't have a namespace conflict, and then call self.find_by_ip from within that once I have got my IP in numerical format? This does work, but does mean that my code is sometimes using find_by and sometimes using get_by (or whatever), which makes it harder for anyone following to debug as it is not consistent.

Thanks

Dan Meyers Network Support, Lancaster University

Hi,

When you call a dynamic finder action (in your case find_by_ip), the
ruby method_missing function is called. This magic functions takes the
function you requested and creates it, which causes your function to
be overwritten in favor of the created function. When you reload!,
your model gets loaded again, and the created function is overwritten
again. This isn't to be expected ofcourse.

Could you file a bug about this on http://dev.rubyonrails.com ?

Regards, DefV

Hi,

When you call a dynamic finder action (in your case find_by_ip), the ruby method_missing function is called. This magic functions takes the function you requested and creates it, which causes your function to be overwritten in favor of the created function. When you reload!, your model gets loaded again, and the created function is overwritten again. This isn't to be expected ofcourse.

I reached that conclusion over on rails-talk, but I'm not entirely
sure what do about it check whether the method that's about to be created exists and if so
use a different (but predictable) name so that in your own find_by_x
function you can call the 'normal' find_by_x

Fred

[mailto:rubyonrails-core@googlegroups.com] On Behalf Of Jan De Poorter

When you call a dynamic finder action (in your case find_by_ip), the
ruby method_missing function is called. This magic functions takes the
function you requested and creates it, which causes your function to
be overwritten in favor of the created function. When you reload!,
your model gets loaded again, and the created function is overwritten
again. This isn't to be expected ofcourse.

I must be missing something, because I don't see how the "manual" method could be overwritten. The creation of the dynamic finder happens in method_missing, which wouldn't be called if the method existed, right?

///ark

Don't use super(), instead construct the call to find yourself. That'll avoid calling method_missing, which will avoid the automatic creation of methods you don't want.

- Matt

He calls super, which calls the method_missing

Right, if the method exists then method_missing won't be called. And that's what's causing the observed behavior.

Initially, he has his hard coded find_by_ip method which gets called. This calls super No super method for find_by_ip is found, so method_missing gets called.

In Rails < 2.0 the dynamic finder methods implementation was inside of method_missing, and afterwards there would still be no find_by_ip and so it would go.

In Rails 2.0 the method_missing method dynamically adds a find_by_ip method, which overwrites the hard coded one (not I said overwrites rather than overrides). So the next time, his method is no longer there to do the parameter conversion thing.

[mailto:rubyonrails-core@googlegroups.com] On Behalf Of Rick DeNatale

No super method for find_by_ip is found, so method_missing gets called.

Ah, in the calling object, not in the superclass.

(note I said overwrites rather than overrides)

Thanks, that's a pet peeve of mine. :slight_smile:

///ark

In Rails 2.0 the method_missing method dynamically adds a find_by_ip method, which overwrites the hard coded one (not I said overwrites rather than overrides). So the next time, his method is no longer there to do the parameter conversion thing.

So is it defining the find_by_ip method on AR::Base or overwriting the original definition? In either case it's a bug but the fix is different.

It has to be overwriting the definition in his subclass of AR::Base, otherwise he wouldn't have seen the problem.

[mailto:rubyonrails-core@googlegroups.com] On Behalf Of Rick DeNatale

It has to be overwriting the definition in his subclass of AR::Base, otherwise he wouldn't have seen the problem.

Let me see if I got this straight.

1) Model#find_x is defined 2) When find_x is called, it calls super, which is AR::Base#find_x. 3) AR::Base has no such method, so method_missing is called in the context of Model (not AR::Base) 4) method_missing generates Model#find_x

So what's weird is that method_missing is adding a method to the subclass that already exists, just because the method can't be found in the superclass.

Am I understanding this right?

///ark

Yes, here's a synopsis of the code from ActiveRecord::Base#method_missing in ActiveRecord 2.0.2, I've replaced some code with #... to make it shorter and more obvious.

module ActiveRecord   #...   class Base     #...     class << self # Class methods      # ...         def method_missing(method_id, *arguments)           if match = /^find_(all_by|by)_([_a-zA-Z]\w*)$/.match(method_id.to_s)             # ...             self.class_eval %{               def self.#{method_id}(*args)                 # body of generated method elided for this post               end             }, __FILE__, __LINE__             send(method_id, *arguments)           elsif match = /^find_or_(initialize|create)_by_([_a-zA-Z]\w*)$/.match(method_id.to_s)             # ...             self.class_eval %{               def self.#{method_id}(*args)                 # Body of method elided for this post               end             }, __FILE__, __LINE__             send(method_id, *arguments)           else             super           end         end      #...      end end

in those two self.class_eval calls, self will be the subclass of ActiveRecord::Base and that's where the method will get defined overwriting the existing method, which got to method_missing by calling super.

There's a ticket open on this issue: http://dev.rubyonrails.org/ticket/10831

and it stemmed from: http://dev.rubyonrails.org/changeset/7510

and: http://dev.rubyonrails.org/ticket/9317

I'd like to see the change rolled back as it makes for a pretty nasty behaving method_missing.

-- tim