I have two models,
User
Membership
The two have the following relationship with one another
user has_many :memberships
I've been trying to figure out where the build method resides, and how do i get it in a list of methods for the instance. Here is the output of the debugger that shows my delima
(rdb:63) #user.memberships.respond_to?"build"
true
While the following is returning false, shouldnt it return true??
(rdb:63) #user.memberships.instance_methods.include?"build"
false
One point is that instance_methods takes an optional boolean parameter, indicating whether you want to see methods of the instances ancestors. In your case I think you want instance_methods(true).
However, it appears that "build" is an autogenerated method, according to the documentation. Typically the autogenerated methods in ActiveRecord are implemented by overriding method_missing and handling calls to "methods" that don't actually exist. responds_to is also overridden so that the class will indicate that it responds to the correct calls. However, since those "methods" aren't actually defined, they won't show up in the instance_methods list.
Since the list of commands that a class can respond_to using method_missing is essentially infinite, I'm pretty sure there's no way to get the list. For example, an ActiveRecord model that has attributes a,b,c, and d will automatically respond to calls such as find_by_a_and_b and find_by_a_b_and_c and find_by_b_and_d and so forth, ad infinitum. There's no way to get a list of all of those possibilities.
Please note that instance_methods returns an array of String or Symbol depending on the Ruby version.
Ruby 1.8 returns an Array of String, Ruby 1.9 an Array of Symbol.
In Ruby 1.8
"".respond_to?(:upcase)
# => true
"".class.instance_methods.include?("upcase")
# => false
"".class.instance_methods.include?(:upcase)
# => false
In Ruby 1.9
"".respond_to?(:upcase)
# => true
"".class.instance_methods.include?("upcase")
# => false
"".class.instance_methods.include?(:upcase)
# => true
Also, instance_methods must be called on the class, not on the instance.
You could try:
#user = User.first
#user.methods.grep /method_name/
However, I don't think you'll see 'build' or 'create' in a list. Most likely these methods are generated dynamically
Related
I am trying to create two callbacks that will be executed dynamically based on a boolean value found in the params hash. How do I implement an If/Else clause to run different callbacks? Do callbacks even have the ability to access data within the params hash?
There's the 'Dirty' methods: link. It doesn't check params, as it works on the Database level, not the Controller side, but it's commonly used with callbacks, because callbacks are chained with Database via before_, after_.
So what I mean is that maybe you don't need to check anything on the controller's side, but check it via Dirty and callbacks. Dirty provides some very useful methods for your case:
You can use '[attribute]_changed?'
'will_save_change_to_[attribute]?'
When you need to track from which value to which value the attribute was changed, you need '[attribute]_change' that will render the array ['value was', 'value changed to'].
Because you're tracking Boolean value, it might have 2-3 values: True, False, nil. If you have 'null: false' constraint in DB, you will have 2 possible values: True, False, so you might use the 1st or 2nd option. Unfortunately, if you don't have such a 'null: false' contstraint, you need to use 3rd option to check what's the current value. For example, you might compare the new value with '.blank?' to verify that nil will be treated as False.
So what you'll have:
before_save :some_callback, if: [attribute]_changed?
# if you need to compare the new_value
before_save :some_callback, if: changed_[attribute]_to_true?
# in private
def changed_[attribute]_to_true?
return unless [attribute]_changed?
[attribute]_change.last.present?
end
That's just an example, it might not work as expected!
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 upgrading an app to Rails 4.2 and am running into an issue where nil values in a field that is serialized as an Array are getting interpreted as an empty array. Is there a way to get Rails 4.2 to differentiate between nil and an empty array for a serialized-as-Array attribute?
Top level problem demonstration:
#[old_app]
> Rails.version
=> "3.0.3"
> a = AsrProperty.new; a.save; a.keeps
=> nil
#[new_app]
> Rails.version
=> "4.2.3"
> a = AsrProperty.new; a.save; a.keeps
=> []
But it is important for my code to distinguish between nil and [], so this is a problem.
The model:
class AsrProperty < ActiveRecord::Base
serialize :keeps, Array
#[...]
end
I think the issue lies with Rails deciding to take a shortcut for attributes that are serialized as a specific type (e.g. Array) by storing the empty instance of that type as nil in the database. This can be seen by looking at the SQL statement executed in each app:
[old_app]: INSERT INTO asr_properties (lock_version, keeps)
VALUES (0, NULL)
Note that the above log line has been edited for clarity; there are other serialized attributes that were being written due to old Rails' behavior.
[new_app]: INSERT INTO asr_properties (lock_version)
VALUES (0)
There is a workaround: by removing the "Array" declaration on the serialization, Rails is forced to save [] and {} differently:
class AsrProperty < ActiveRecord::Base
serialize :keeps #NOT ARRAY
#[...]
end
Changing the statement generated on saving [] to be:
INSERT INTO asr_properties (keeps, lock_version) VALUES ('---[]\n', 0)
Allowing:
> a = AsrProperty.new; a.save; a.keeps
=> nil
I'll use this workaround for now, but:
(1) I feel like declaring a type might allow more efficiency, and also prevents bugs by explicitly prohibiting the wrong data type being stored
(2) I'd really like to figure out the "right" way to do it, if Rails does allow it.
So: can Rails 4.2 be told to store [] as its own thing in a serialized-as-Array attribute?
What's going on?
What you're experiencing is due to how Rails 4 treats the 2nd argument to the serialize call. It changes its behavior based on the three different values the argument can have (more on this in the solution). The last branch here is the one we're interested in as when you pass the Array class, it gets passed to the ActiveRecord::Coders::YAMLColumn instance that is created. The load method receives the YAML from the database and attempts to turn it back into a Ruby object here. If the coder was not given the default class of Object and the yaml argument is nil in the case of a null column, it will return a new instance of the class, hence the empty array.
Solution
There doesn't appear to be a simple Rails-y way to say, "hey, if this is null in the database, give me nil." However looking at the second branch here we see that we can pass any object that implements the load and dump methods or what I call the basic coder protocol.
Example code
One of the members of my team built this simple class to handle just this case.
class NullableSerializer < ActiveRecord::Coders::YAMLColumn
def load(yaml)
return nil if yaml.nil?
super
end
end
This class inherits from the same YAMLColumn class provided by ActiveRecord so it already handles the load and dump methods. We do not need any modifications to dump but we want to slightly handle loading differently. We simply tell it to return nil when the database column is empty and otherwise call super to work as if we made no other modification.
Usage
To use it, it simply needs to be instantiated with your intended serialization class and passed to the Rails serialize method as in the following, using your naming from above:
class AsrProperty < ActiveRecord::Base
serialize :keeps, NullableSerializer.new(Array)
# …
end
The "right" way
Getting things done and getting your code shipped is paramount and I hope this helps you. After all, if the code isn't being used and doing good, who cares how ideal it is?
I would argue that Rails' approach is the right way in this case especially when you take Ruby's philosophy of The Principle of Least Surprise into account. When an attribute can possibly be an array, it should always return that type, even if empty, to avoid having to constantly special case nil. I would argue the same for any database column that you can put a reasonable default on (i.e. t.integer :anything_besides_a_foreign_key, default: 0). I've always been grateful to past-Aaron for remembering this most of the time whenever I get an unexpected NoMethodError: undefined method 'whatever' for nil:NilClass. Almost always my special case for this nil is to supply a sensible default.
This varies greatly on you, your team, your app, and your application and it's needs so it's never hard and fast. It's just something I've found helps me out immensely when I'm working on something and wondering if amount could default to 0 or if there's some reason buried in the code or in the minds of your teammates why it needs to be able to be nil.
In a plugin I am writing I am using alias to override one of the default Rails validators like so:
# Alias the original validator so it's still available under a different name
alias original_validates_uniqueness_of :validates_uniqueness_of unless method_defined?(:original_validates_uniqueness_of)
# Then alias the custom validator under the original name
alias validates_uniqueness_of :custom_validates_uniqueness_of
This all works pretty well. When "validates_uniqueness_of" is defined on an attribute in a AR model, it will use my "custom_validates_uniqueness_of" method instead. Validations are running as expected.
However, when I call:
SomeARclass.respond_to?(:validates_uniqueness_of)
..it will return false. This behavior will mess with several popular plugins.
My question:
Why is respond_to returning "false"? Is this behavior the result of alliasing? How can adjust my custom validator to make it return true?
Thank you for your help.
Erwin
Your sample, on the surface, looks like it should work. I expect you've found that, inside of the class body for class SomeARclass, you actually can call validates_uniqueness_of.
class SomeARclass
validates_uniqueness_of :first_field # works
end
However, I expect that scoped_validates_uniqueness_of is a private method. That's why you have been unable to send that message to SomeARclass from outside of its class body.
SomeARclass.validates_scoped_uniqueness_of :first_field # fails
#=> NoMethodError: private method "validates_scoped_uniqueness_of" called
for SomeARclass:Class
When you alias a private method with a new name, such as aliasing the private method validates_scoped_uniqueness_of with the new name validates_uniqueness_of, then that new method is also private. I expect that's what happened here.
The documentation for #respond_to? reads:
- (Boolean) respond_to?(symbol, include_private = false)
Returns true if obj responds to the given method. Private methods are included in the search only if the optional second parameter evaluates to true.
I have a Gem that deals with images that get modified. I want to modify it to update the old image but, I need to be able to get the object id.
Right now it uses the following code:
def respond_to?(method,*args, &block)
puts ("++++METHOD #{method.to_s} ARGS #{args} BLOCK #{block}")
args.each do |value|
puts ("ARGS #{value}")
end
but I don't know how to get id from something I pass in nor do I know how to pass the id in, I've tried
#asset.image.s_245_245(:asset_id=>#asset.id) with no success. Args returns nothing. What am I doing wrong?
Update: I am currently reading http://www.simonecarletti.com/blog/2009/09/inside-ruby-on-rails-extract_options-from-arrays/
Update: This too returned blank.
Your question is very unclear. How is the method respond_to? related to your problem with object id?
I am guessing that in reality you wanted to override method_missing, because now you do not call respond_to?, or it is not shown in your examples.
If you have not defined such method, calling image.s_245_245 will trigger method_missing (in the image object) with the parameters you used for respond_to?.
There is a rule, which says that if you use method_missing to handle some calls, then you should also modify respond_to?, and make it returning true when asked for the methods handled by method_missing.
As for object ID, there are two possibilities:
Every object in ruby responds to .object_id (which returns an internal identifier of every object)
ActiveRecord objects respond to .id (which is a primary key in the database).
This is just a side-note, because I suppose that if you start experimenting with method_missing instead of respond_to? you will know which one you want.