I have an ActiveRecord class MyClass with some fields in the database and which includes this concern:
module Wrapper
extend ActiveSupport::Concern
included do
puts self #=> MyClass
puts self.columns #=> Array of ActiveRecord::ConnectionAdapters::PostgreSQLColumn
end
end
The first time I access this class (e.g. MyClass.first) I get the expected output (as above).
If I try calling MyClass.first a second time then no output appears, and if I run MyClass.columns without including the concern I get:
output error: #<NoMethodError: undefined method 'name' for #<Object:0x007fd1f20d0ef0>>
Can you help me understand what's going on here?
The method in question is ActiveRecord::Attributes::ClassMethods#columns.
I understand that the code in the included block is scoped to the context of the class which makes sense (making this issue more mysterious).
It would also be great if you could:
Let me know how I could have debugged it further (e.g. how do I identify which object it is that doesn't have the 'name' method)?
Point me to any resources / tutorials that explain this concept
I'm running Rails 4.2.0 and Ruby 2.2.0
Related
Here is my code:
class Order < Grape::Entity
expose :id { |order, options| order.id.obfuscate }
expose :time_left_to_review do |order, options|
byebug
order&.time_left_to_review # ERROR
end
expose :created_at { |order, options| order.last_transition.created_at }
end
# NoMethodError Exception: undefined method `time_left_to_review' for #<Order:0x007f83b9efc970>
I thought &. is a shortcut for .try but I guess I was wrong. May someone point me to the right direction regarding what I am missing?
I feel like it's not ruby related. Grape maybe? Though I don't get how it could be.
&. works like #try!, not #try.
And here is description of #try! (from documentation):
Same as #try, but will raise a NoMethodError exception if the receiving is not nil and does not implemented the tried method.
So basically it saves you from calling a method on nil, but if an object is presented it will try to call its method as usual.
The quote is from Rails Documentation, and so it's important to emphasize
that Ruby does not provide #try; it's provided by Rails, or more accurately ActiveSupport. The safe navigation operator (&.) however, is a language feature presented in Ruby 2.3.0.
The try method ignores a lot of things, it just gives it a shot and calls it a day if things don't work out.
The & conditional navigation option will only block calls on nil objects. Anything else is considered to be valid and will proceed with full consequences, exceptions included.
I am arriving to the party a bit late here, the other answers have covered how it works, but I wanted to add something that the other answers have not covered.
Your question asks What is the difference between try and &. in Ruby. Ruby being the key word here.
The biggest difference is that try doesn't exist in Ruby, it is a method provided by Rails. you can see this or yourself if you do something like this in the rails console:
[1, 2, 3].try(:join, '-')
#=> "1-2-3"
However if you do the same thing in the irb console, you will get:
[1, 2, 3].try(:join, '-')
NoMethodError: undefined method `try' for [1, 2, 3]:Array
The &. is part of the Ruby standard library, and is therefore available in any Ruby project, not just Rails.
In addition to the above answers, I am adding some examples.1
account = Account.new(owner: Object.new)
account.try(:owner).try(:address)
# => nil
account&.owner&.address
# => NoMethodError: undefined method `address' for #<Object:0x00559996b5bde8>`
account.try!(:owner).try!(:address)
# => NoMethodError: undefined method `address' for #<Object:0x00559996b5bde8>`
As we can see, try doesn't check if the receiver responds to the given method or not. Whereas try! and &. behaves the same. If the receiver responds to the address method, all of them will return the same result. I prefer using &. as it looks more cleaner.
For more information on The Safe Navigation Operator (&.), I have found this blog really helpful https://mitrev.net/ruby/2015/11/13/the-operator-in-ruby/
I am using a development script file to check out new possible ideas. Recently I tried to monkey patch MyDBObject from within that script file.
Assume an empty dev.rb file and add a monkey patch right in the top like so:
class MyDBObject
def test_function
'function works'
end
end
Starting up the pry console and loading the file yields random results.
First I received:
NoMethodError: undefined method `relations' for MyDBObject:Class
Later the script loaded, but I couldn't access the original class any longer:
undefined method `first' for MyDBObject:Class
I noticed that prepending the line:
MyDBObject
right before the monkey patching, the intended functionality is achieved.
This appears to be some sort of lazy loading of the class objects. Can somebody cast some light on this for me please?
Depending on the order in which source files are loaded, you'll either be redefining the entire class, or having your changes replaced.
I highly recommend giving this a read: http://www.justinweiss.com/articles/3-ways-to-monkey-patch-without-making-a-mess/ (TLDR - put your patch in a module and explicitly include it)
I've followed this guide:
http://guides.rubyonrails.org/plugins.html#add-an-acts-as-method-to-active-record
In fact, I've actually copied the code and put into my app and it doesn't work.
I keep getting undefined method errors.
When I use console, I can check if the module is initialized and it is, but the model that uses the "acts_as" method throws undefined method errors.
Also in console I can call ActiveRecord::Base.send :include, ... explicitly and then it includes the module -- then everything works. But try as I may, I can't get rails to call .send on ActiveRecord::Base at load time.
Any ideas?
I'm trying to use modules for namespacing reasons. I have this file located in my Rails app at /lib/reports/stripe.rb.
module Reports
module Stripe
def self.foo
puts 'i am foo'
end
end
end
In my console, I'd expect to be able to call foo by Reports::Stripe.foo or Reports::Stripe::foo, but I get the error
NoMethodError: undefined method `foo' for Reports::Stripe:Module
What am I doing wrong? Also feel free to let me know if there's a better way to organize the location and namespacing.
All method calls in ruby use the . syntax. Even "module" methods.
> Reports::Stripe.foo
i am foo
You may be receiving the error NoMethodError: undefined method 'foo' for Reports::Stripe:Module if you have added the method after you have started the rails console. Try restarting the console or reloading the file with load 'reports/stripe'.
The file was actually located in /lib/reports/stripe/stripe.rb. It was a mistake I made much earlier, but forgot to fix. Moving the file to /lib/reports/stripe.rb resolved the issue.
I want to check when attributes on a model have changed. I have attempted to check values != the value on the form before doing a save but that code is really ugly and is not working well at times. Same with using update_column which does not do the validations in my model class. If I use update_attributes without doing something else I will not be able to check when a field has been updated from my understanding. From my web research on Stack Overflow and other sites it appears that using ActiveModel Dirty is the way to go.
I have looked at this: http://api.rubyonrails.org/classes/ActiveModel/Dirty.html
My hope is to use this to check if boolean flags changed on a model after using update_attributes. I attempted to do the minimum implementation as described in the included link. I added the following to my ActiveRecord class:
include ActiveModel::Dirty
define_attribute_methods [:admin]
I tried adding the three attributes I wanted to keep track of. I started with just one attribute to see if I could get it working. I received the following error when I ran an rspec test. Once I removed the argument I had no errors.
Exception encountered: #<ArgumentError: wrong number of arguments (1 for 0)>
After I removed the argument I decided to include similar methods in my model using admin instead of name. Other Rspec tests broke on the save method. However I feel the problem is with how I am implementing ActiveModel Dirty.
I have read on other Stack Overflow posts where commenters stated that this was included in 3.2.8 so I upgraded from 3.2.6 to 3.2.8. I did not understand what that meant so after getting errors I decide just to leave the include ActiveModel::Dirty statement and try to use admin_changed? Of course it did not work.
I have not been able to find anything about how to initially set things up for this other than the link I included here. All the other research I have found assumes that the initial setup was correct and that updating to the current stable version of Rails would take care of their problems.
Any help would be appreciated on how to implement this. Doing the minimal implementation as stated in the link is not working. Maybe there is something else I am missing.
The problem appears to be that ActiveRecord redefines the define_attribute_methods method to accept 0 arguments (because ActiveRecord automatically creates attribute methods for every column in the database table): https://github.com/rails/rails/blob/master/activerecord/lib/active_record/attribute_methods.rb#L23
This overrides the define_attribute_methods method provided by ActiveModel: https://github.com/rails/rails/blob/master/activemodel/lib/active_model/attribute_methods.rb#L240
Solution:
I figured out a solution that worked for me...
Save this file as lib/active_record/nonpersisted_attribute_methods.rb: https://gist.github.com/4600209
Then you can do something like this:
require 'active_record/nonpersisted_attribute_methods'
class Foo < ActiveRecord::Base
include ActiveRecord::NonPersistedAttributeMethods
define_nonpersisted_attribute_methods [:bar]
end
foo = Foo.new
foo.bar = 3
foo.bar_changed? # => true
foo.bar_was # => nil
foo.bar_change # => [nil, 3]
foo.changes[:bar] # => [nil, 3]
However, it looks like we get a warning when we do it this way:
DEPRECATION WARNING: You're trying to create an attribute `bar'. Writing arbitrary attributes on a model is deprecated. Please just use `attr_writer` etc.
So I don't know if this approach will break or be harder in Rails 4...
See also:
Track dirty for not-persisted attribute in an ActiveRecord object in rails
https://github.com/adzap/validates_timeliness/issues/73
Try adding adding =, like this:
define_attribute_methods = [:admin]
That change worked for me. Not sure if it has something to do with this?