I'm looking for way to see currently executing code. My reason is: I have ruby classes, that are been monkey patched by lots of patches, so its close to impossible to track which methods were changed. Is there any way to check what code has been loaded into memory and currently executing?
Ask for more details if you need
Another way besides the debugger mentioned by tessi, would be to use ruby-prof to benchmark the whole application and analyze the generated tree.
Every called method is in there, so the desired or not desired versions as well.
Getting the Origin of a Method
In ruby 1.9 and newer, you can open a debugger/console at any point and ask the method for it's source location.
For example, when looking for the definition of the admin? method of my User class I can do the following:
user = User.first
=> #<User id: 1, ...>
user.method(:admin?).source_location
=> ["/Users/tessi/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/activemodel-4.0.13/lib/active_model/attribute_methods.rb", 382]
It tells me that the admin? method is defined in ActiveModel in the file above and in line 382 of that file.
In a similar way you could iterate over all methods of your class and check the origin of the methods:
user.methods.map {|method_name| user.method(method_name).source_location}
Monkey Patching
This still works with patched classes. When opening a rails console, I can edit my User class and look at the source_location again:
class User < ActiveRecord::Base
def admin?
puts 'the patched admin? method'
super
end
end
User.first.method(:admin?).source_location
=> ["(pry)",2]
Now, the method's location is in my console (pry) at statement 2. This works, because my patch creates a new Method-object which replaces the old method in the method dictionary of the User class. The new method object returns a different source_location.
Related
I am using the Audited gem in my application for tracking user log. Everything is working fine except for current user tracking.
In my case, I have 2 models: Instructor and Student. Instructor will be the current_admin_user, and I need to find the student manually.
To overcome this issue, I tried to override current_user_method and create an audited.rb file in the initializers with below content:
Audited.current_user_method = :current_admin_user
This is working fine, but when I use any other method like current_user_or_student ...
Audited.current_user_method = :current_user_or_student
in application_controller.rb ...
def current_user_or_student
current_admin_user || InstructorStudent.find_by_id(id)
end
it is not going into this method, even current_admin_user is also not storing in audits.
Why isn't my current_user_or_student method being called when overriding it in application_controller.rb?
Finally I resolved my issue, I am using STI (single table inheritance) .
my other controllers of instructor was not inherite from application controller. so my current_user_or_student was not called for instructor login .
To overcome this issue, i create one controller concern called audited_user.rb
and write following method in concern
def current_user_or_student
current_admin_user || InstructorStudent.find_by_id(id)
end
and included this concern in both my instructor base controller and application controller.
now everything is working fine and my audited user is also save correctly.
I hope this will save any others day.
You have defined current_user_or_student as such:
def current_user_or_student
current_admin_user || InstructorStudent.find_by_id(id)
end
Assuming current_admin_user is nil, it will try to find InstructorStudent. You are using find_by_id which will return nil if the InstructorStudent with that id cannot be found. It's likely that is what is happening. It's not clear from this source what id is -- are you sure it's set to an id that can be found in instructor_students? I would encourage you to do the following to debug:
def current_user_or_student
current_admin_user || InstructorStudent.find(id)
end
This will raise an error if the method's conditional falls through to the InstructorStudent.find branch and the id cannot be found. If my hypothesis is correct, this will prove that the id cannot be found, so your original code is returning nil (while this updated code now errors instead). The error message will also tell you what the value of id is which you can use for further debugging.
Alternatively, you can debug this without changing code by running a request that you expect to be audited but isn't and then inspecting the server logs. You will see the queries run there and may be able to debug that way as well.
I'm working with a massive legacy code base, so I am looking for advice concerning this particular issue, please, not suggestions of better high-level implementations.
A simplified version of what I'm working with:
class Order < ActiveRecord::Base
has_many :line_items
#other stuff
def balance
#some definition
end
end
class LineItem < ActiveRecord::Base
belongs_to :order
#other stuff
end
module Concerns
module LineItems
module Aggregates
extend ActiveSupport::Concern
#stuff
def balance
#some other definition
end
end
end
end
Order has a method called 'balance,' and a module of LineItem also has a method called 'balance.' It seems that most of the time (in most places in the code base), when specific_line_item.balance is called, it used the method definition under the LineItem module, but there are a couple of places where it instead calls the method from Order.
Is there any way in Ruby/Rails to specify on method call which of these two I'd like to use? OR is there probably something else going on here because Ruby doesn't have method overloading, so the problem I'm describing here isn't possible?
All relevant cases where either method is called are coming from a line_item (i.e. specific_line_item.balance), so I would think it would always choose the method closer to home, rather than making the associative jump and calling Order's 'balance' method without being told to.
EDIT:
Thanks for the responses! It seems I wasn't clear enough with my question. I understand the difference between
Order.first.balance
and
LineItem.first.balance
and that the balance method being called is the one defined within the class for that object. In the situation I'm describing, I observed, in the actual live app environment, that at a place in the code where
LineItem.find(some_id).balance
was called it output not the result that would be computed by the LineItem 'balance' method, but the one from the Order class.
So I had hoped to learn that there's some ruby quirk that might have an object call an associate's method of the same name under some conditions, rather than it's own. But I'm thinking that's not possible, so there's probably something else going on under the covers specific to this situation.
Firstly, ActiveRecord::Concern can change a lot of behaviour and you've left out a lot of code, most crucially, I don't know where it's being injected, but I can make an educated guess.
For a Concern's methods to be available a given object, it must be include'd in the object's class's body.
If you have access to an instance of the Order object, at any point you can call the balance method:
order = Orders.last # grab the last order in your database
order.balance # this will call Order#balance
And if you have the Order then you can also get the LineItem:
order.line_items.first.balance # should call the Concerns:: LineItems::Aggregates#balance
You can open up a Rails console (with rails console) and run the above code to see if it works as you expect. You'll need a working database to get meaningful orders and balances, and you might need to poke around to find a completed order, but Ruby is all about exploration and a REPL is the place to go.
I'd also grep (or ag or ack) the codebase looking for calls to balance maybe doing something like grep -r "(^|\s)\w+\.balance" *, what you want to look for is the word before .balance, that is the receiver of the "balance" message, if that receiver is an Order object then it will call Order#balance and if it is a LineItem object then it will call Concerns:: LineItems::Aggregates#balance instead.
I get the feeling you're not familiar with Ruby's paradigm, and if that's the case then an example might help.
Let's define two simple Ruby objects:
class Doorman
def greet
puts "Good day to you sir!"
end
end
class Bartender
def greet
puts "What are you drinking?"
end
end
Doorman and Bartender both have a greet method, and which is called depends on the object we call greet on.
# Here we instantiate one of each
a_doorman = Doorman.new
a_bartender = Bartender.new
a_doorman.greet # outputs "Good day to you sir!"
a_bartender.greet # outputs "What are you drinking?"
We're still using a method called greet but the receiver is what determines which is called.
Ruby is a "message passing language" and each "method" is not a function but it's a message that is passed to an object and handled by that object.
References
How to use concerns in Rails 4
http://api.rubyonrails.org/classes/ActiveSupport/Concern.html
http://guides.rubyonrails.org/command_line.html#rails-console
I am new to rails and notice a very odd pattern. I thought some error messages in Django were obscenely cryptic, but building my second app in rails I notice my errors come up NoMethodError more than 90% of the time.
How do rails people tell the difference between all these errors with the same name?
What does NoMethodError mean at it's core? It seems like what you're calling in the template is misspelled, or you're accessing attributes that don't exist?
Where can this error happen? Is the only possible cause in the template/view (the html.erb file)? Or can a bad call in the controller and whatnot cause same error?
Also, what is the best debugger gem to alleviate these issues? Reading the full trace isn't too helpful for beginners at least for a while, I;d like a first hand account of what debugger someone uses instead of reading hype
Thank you kindly
NoMethodError means you are calling a method on an object, but that object doesn't provide such method.
This is a quite bad error in the sense that is reveals a poorly designed and tested application. It generally means your code is not behaving as you are expected.
The way to reduce such errors is:
Make sure that when you are writing the code you are taking care of the various edge cases that may happen, not just the correct path. In other words, you need to take care of validating what's going on and making sure that if something is not successful (e.g. the user is not supplying all the input requested) your application will handle the case gracefully.
Make sure you write automatic test cases that covers the behavior of each method in your codebase
Keep track of the errors. When an error occurs, write a test to reproduce the behavior, fix the code and check the test passes. That will reduce the risk of regression.
This is not a Rails specific error actually. I'll try to explain what's happening at its core.
Ruby is a language that functions through message passing. Objects communicate by sending messages to each other.
The message needs to be defined as a method on the object to respond to it. This can be directly defined on the object itself, the object's class, the object's class's parents/ancestors or through included modules.
class MyObject
def some_method
puts "Yay!"
end
end
> MyObject.new.some_method
Yay!
Objects can define method_missing to handle unexpected messages.
class MyObject
def method_missing(name, *args, &block)
puts name
end
end
> MyObject.new.some_undefined_method
some_undefined_method
Without the method_missing handler, the object will raise a NoMethodError
class MyObject
end
> MyObject.new.some_undefined_method
NoMethodError: undefined method 'some_undefined_method' for #<MyObject...>
So what does this look like in Rails?
$ rails generate model User name:string
Produces this
# models/user.rb
class User < ActiveRecord::Base
end
Which has the following methods implemented among others (by ActiveRecord)
def name
end
def name=(value)
end
When you do the following:
# create a new User object
> user = User.new
#<User ... >
# call the 'name=' method on the User object
> user.name = "name"
"name"
# call the 'name' method on the User object. Note that these are 2 different methods
> user.name
"name"
> user.some_undefined_method
NoMethodError: undefined method 'some_undefined_method' for #<User...>
You'll see the same results whether you're calling it in your console, your model, your controller or in the view as they're all running the same Ruby code.
ERB view templates are slightly different in that what you enter is only evaluated as Ruby code when it's between <% %> or <%= %>. Otherwise, it gets written out to the page as text.
How do rails people tell the difference between all these errors with
the same name?
We usually look at the stack trace that comes back with the response (in development mode) as well as looking in the logs. In a dev environment, I am running my server in a console where I can scroll through the request.
What does NoMethodError mean at it's core? It seems like what you're
calling in the template is misspelled, or you're accessing attributes
that don't exist?
Due to dynamic coupling nature of Ruby. When Ruby determines that an object doesn't have a method by the name of the one that was called. It looks for a method by the name of "method_missing" within that object. If it's not defined then the super one is called which has the default behaviour of raising an exception. Rails leverages this mechanism heavily in it's internal dispatching
Where can this error happen? Is the only possible cause in the
template/view (the html.erb file)? Or can a bad call in the controller
and whatnot cause same error?
This error can happen wherever you have Ruby code, It has nothing to do with rails
Also, what is the best debugger gem to alleviate these issues? Reading
the full trace isn't too helpful for beginners at least for a while,
I;d like a first hand account of what debugger someone uses instead of
reading hype
An Invaluable tool for debugging is the gem 'pry'. It has many useful plug-able tools that greatly simplify debugging
To do a special kind of validation in an ActiveRecord-based model I need to manually do the update_attributes-steps:
load(params) && save
But when I try to call "load" on my Model's instance (mymodel.load(params)) it calls "load" on ActiveSupport, trying to load a file.
Is there a way to tell Rails to use the ActiveRecord-method?
Thanks!
Regards
Marc
I think you want the assign_attribute method of ActiveRecord::Base.
I'm using Rails 3.1.3, but hopefully this is correct for you.
The update_attributes source you pasted belongs to ActiveResource::Base, not toActiveRecord::Base. I just made that mistake myself: Is it possible to call ActiveResource::Base#load? ActiveRecord::Base does not supply a load method. Instead the load method of Object is called, which appears to be supplied by ActiveSupport's Loadable module in activesupport-3.1.3/lib/active_support/dependencies.rb.
Straight from the source:
# File activerecord/lib/active_record/base.rb, line 2665
def update_attributes(attributes)
self.attributes = attributes
save
end
Actually it's rails 2, but I imagine it didn't change all that much.
When my system requires two classes or modules of the same name, what can I do to specify which I mean?
I'm using rails (new to it), and one of my models is named "Thread". When I try to refer to the class "Thread" in thread_controller.rb, the system returns some other constant of the same name.
<thread.rb>
class Thread < ActiveRecord::Base
def self.some_class_method
end
end
<thread_controller.rb>
class ThreadController < ApplicationController
def index
require '../models/thread.rb'
#threads = Thread.find :all
end
end
When I try Thread.find(), I get an error saying that Thread has no method named find. When I access Thread.methods, I don't find my some_class_method method among them.
Any help? (And don't bother posting "just name your model something else." It's not helpful to point out obvious compromises.)
You could put your app into its own namespace.
<my_app/thread.rb>
module MyApp
class Thread
end
end
No really, name your model something else.
Thread is a reserved constant in Ruby and overriding that constant is only going to make you run into trouble. I compromised for my application and called it Topic instead.
If you absolutely must overwrite an existing constant, you can do something like this:
# use Object to make sure Thread is overwritten globally
# use `send` because `remove_const` is a private method of Object
# Can use OldThread to access already existing Thread
OldThread = Object.send(:remove_const, :Thread)
# define whatever you want here
class MyNewThread
...
end
# Now Thread is the same as MyNewThread
Object.send(:const_set, :Thread, MyNewThread)
Obviously anything that relied on the pre-existing Thread would be busted unless you did some kind of monkey-patching.
Just because this kind of thing can be done, doesn't mean it should be. But in certain circumstances it can be handy, for example in tests you can override a remote data source with your own 'dumb' object.