Why would I get NoMethodError on my Heroku app when the same code works flawlessly on my local setup?
The error is triggered by this code:
#customer = Customer.find(1)
#customer.responses.create(:offer_id => '1', :digit => '2')
That code works as intended on my local server and in my local Rails console.
However, on Heroku the above code triggers NoMethodError:
NoMethodError (undefined method `responses' for #<Customer:0x7f7bcbee3808>):
The Response model is tied to the Customer model by means of belongs_to :customer
Additionally, I can login to the Heroku console and run this without any problems:
Response.create(:offer_id => '1', :customer_id => '1', :digit => '2')
So if the above works and both versions work fine on my local box, why would the association fail on Heroku?
--
Running Rails 3.0.6 and tested on Heroku Ruby 1.8.7 and Ruby 1.9.2
Databases are identical on Heroku and on my local box.
Usually when something like this doesn't work it indicates you're missing a has_many association. You need to define both the belongs_to and has_many sides of the association if you wish to access them both.
By the sounds of it, if it's working on your local machine but not Heroku then it would be because you haven't pushed the changes to the Heroku server and restarted the console there. Please make sure you have pushed the changes and try again.
Marco, I thought about this a bit, and I have a few guesses for you to try. Before you do either of these, restart your app. Sometimes that does miracles.
heroku restart
Ok, now, try in console just
#customer.responses
What does that return? I assume it should be []. Maybe doing some inspection etc. of that can give us insights here. If you build and associate a response manually can you get it to show up?
Second, your no method error is on responses, not on create, so whatever you type after that probably doesn't matter, BUT, are your offer_id and digit fields integers? If so, try creating them using integers, not strings. PostgreSQL is so fragile compared to MySQL or SQLite, I've had loads of issues that trace back to my unfamiliarity working with Postgre prior to developing on Heroku.
#customer.responses.create(:offer_id=>1,:digit=>3)
That probably doesn't matter but it's worth checking out.
The other thing to check is all your callbacks and validations etc. Is anything failing? It may not seem related but I've had issues before where things acted very weird because of seemingly tiny silent failures in a callback that I had overlooked. I'm sure you're testing as you go, but if you've got shallow test coverage anywhere on this model you might as well use this bug hunt as a chance to beef it up :)
Sympathies on the error, I don't know if any of this will help, but good luck! Please post if Heroku staff find the issue, I'd be very interested to learn from it!
I think you problem is how you are creating the response:
#customer.responses.create(:offer_id => '1', :digit => '2')
You might want to try this instead.
Response.create(:offer_id => '1', :digit => '2', :customer_id => 1)
Related
My own computer: MacOS
Production: Heroku
App: RoR with MySQL database (setup correctly both locally and in production)
ModelTwo has_many ModelOne
ModelOne belongs_to ModelTwo
ModelTwo uses self.model_one.any? to make a decision
This works fine, 100% ok, in development and test (RSpec) environments.
In production (Heroku), self.model_one.any? always returns false.
Doing heroku run rails c everything runs smoothly. I can see the records, make the EXACT SAME CALLS AS MY CODE (literally cmd+c cmd+v from Atom to console), and it all works like it should. I get true when it should be true and false when it should be false.
The app doesn't crash, because it's not a critical decision, but it does end up using a more performance-demanding block, which is exactly what I'm hoping to avoid by creating this conditional.
I've been trying to figure this out for a while, so one of the things I did do is put puts statements all over the place, to track each change/save to ModelOne and also how ModelTwo is getting data at each point.
It turns out, ModelTwo seems blind to ModelOne completely. Not only does self.model_one.any? always return false, but also ModelOne.count always return 0. Even when rails c reads it correctly and other Models and Controllers in the app do, too!
Again, this is ONLY happening in Heroku production.
Development is 100% ok! I know from watching rails s as I navigate the app. All of my puts statements show data and Models working as they should.
Tests are 100% ok! I made sure my RSpec ModelTwo test was testing THIS decision specifically and it passes!
WHAT IS GOING ON?? What am I missing?
Rails have different environments. And different database for each environment. If you have records in development or production db, they are not present in test db.
So rails c could give a different result.
It is hard to analyze without code examples, but I assume you have validation errors please check model_one_entity.errors.
I would assume issues in controller strong parameters, but if you have ModelOne.count zero, then it does not create it at all, so you need to check validations. Or use create! and save! methods instead of create and save
I'm using the latest version of the Impressionist and Rails Admin gems, and wondering if anyone could shed some light on an annoying conflict I'm experiencing. The problem is roughly documented here - https://github.com/sferik/rails_admin/issues/1315, yet the vaguely described solution is not working for me. When I have the line is_impressionable in my Listing model, I get an error when starting my Rails server with rails s:
...rvm/gems/ruby-2.0.0-p247/gems/activerecord-4.0.2/lib/active_record/dynamic_matchers.rb:22:in `method_missing': undefined local variable or method `is_impressionable' for Listing(no database connection):Class (NameError)
If I first start the server, and then add the 'is_impressionable' line, everything works fine, so the problem only occurs during initialization. I don't fully understand the initialization process, so am not sure how to go about getting this to work.
I have tried moving all my rails_admin model configuration options to their respective models, rather than in the initializer, which had no effect. I also have the following line in my initializer:
config.included_models = [Listing,ListingImage,AllOtherModelsHere...]
I have tried adding single quotes around these model names, which results in the following errors, as described in the github issue here
[RailsAdmin] Could not load model Listing, assuming model is non existing. (undefined local variable or method `is_impressionable' for Listing(no database connection):Class)
Any ideas what else I can try to make these gems work together? I don't want to have to remove the is_impressionable line every time I want to restart the server or generate a migration...
Not sure if the same issue that I had but yet I will post what worked for me just in case someone struggles with this too:
Im on a ruby 2.1.5 project with rails 4.2.0 and among other gems I'm using rails admin.
I run into several weird problems trying to set this up. For instance if I added the is_impressionable call within one of my models for some reason the execution of that file stopped there and I started getting weird errors like any method declared below the is_impressionable failed with undefined error.
So what I end up doing was:
class MyModel < ActiveRecord::Base
include Impressionist::IsImpressionable
is_impressionable
end
So this solved my issue and now i can access #my_model_instance.impression_count as expected.
I changed every occurrence of Klass to 'Klass'.constantize in initializer.
I recently upgraded an app i was working on to rails 3.1rc5..
For the most part it's been great but a few of my tests are having really weird issues..
For example in one of my cucumber specs i create a bunch of fake records using factory girl.. usually this works fine but it seemed that it wasn't creating the records for some reason..
So I commented out all of my factory stuff and replaced it with this:
c = Contact.new(:first_name => "SOMEONE", :last_name => "COOL", :dob => 10.years.ago, :sex => "male")
if c.save
puts "MYCOUNT: #{Contact.count}"
else
puts "EXPLOSIONS!!!"
end
Running this as part of the cucumber suite outputs this:
MYCOUNT: 0
So the contact record is obviously being saved (and passing validations) yet it is still not showing up when i call count??
Why??
I am using:
Rails 3.1rc5
rspec-rails
cucumber-rails
and
factory_girl_rails
I should also probably note i'm indexing my models using sunspot (solr API) https://github.com/outoftime/sunspot
It sounds like you've got a transaction rollback firing within your test:
1) Transaction opened
2) Contact.save succeeds (now have legit Contact instance and db record)
3) Something goes wrong, raises ActiveRecord::Rollback
4) Transactions rolls back, leaving legit Contact instance but no db record, count = 0
I don't know what would cause this related to your Rails upgrade, but perhaps this will help you find what's failing.
EDIT:
If you tail your log/test.log file you should see a Rollback occur if this is the case. You can look at the previous DB activity to get a clue as to what the last successful db operation was before it.
Not an exact science, but may help you decide if this is the case and get a rough idea of where it went sideways.
I have a set of Test::Unit tests for a Rails application. It was developed on OS X under Ruby 1.8.6, Rails 2.3.4.
I'm also using thoughtbot-shoulda 2.10.2.
I'm using standard Rails fixtures, not factories.
I've checked out the project onto a CentOS Linux 5 workstation for another developer to work on. He's running Ruby 1.8.7.
(The app is running on CentOS Linux 5 in production, and it's working fine there.)
On my coworker's CentOS dev machine, all of the unit tests are passing.
However, most, but not all, of the functional tests are erroring out. I've isolated one test (removing all the others from the project) to narrow down the troubleshooting scope.
context 'on DELETE to :destroy' do
setup {
delete(:destroy, { :id => addresses(:mary_publics_address).id }, stans_id)
}
should 'delete the address' do
assert Address.find(:all, :conditions => {
:id => addresses(:mary_publics_address).id
} ).blank?
end
should 'delete the addresses phone numbers' do
assert PhoneNumber.find(:all, :conditions => {
:id => phone_numbers(:mary_publics_phone_number).id
} ).blank?
end
end
The error we're getting is...
[abc#abc contactdb]$ rake test:functionals --trace
(in /home/abc/projects/contactdb)
[ ... ]
/usr/local/ruby_187/bin/ruby -I"lib:test" "/home/abc/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/functional/addresses_controller_test.rb"
Loaded suite /home/abc/.gem/ruby/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader
Started
.E
Finished in 0.426749 seconds.
1) Error:
test: on DELETE to :destroy should delete the addresses phone numbers. (AddressesControllerTest):
ActiveRecord::RecordNotFound: Couldn't find Address with ID=1254595889
/test/functional/addresses_controller_test.rb:107:in `__bind_1255114457_160068'
/usr/local/ruby_187/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.2/lib/shoulda/context.rb:369:in `call'
/usr/local/ruby_187/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.2/lib/shoulda/context.rb:369:in `run_current_setup_blocks'
/usr/local/ruby_187/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.2/lib/shoulda/context.rb:368:in `each'
/usr/local/ruby_187/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.2/lib/shoulda/context.rb:368:in `run_current_setup_blocks'
/usr/local/ruby_187/lib/ruby/gems/1.8/gems/thoughtbot-shoulda-2.10.2/lib/shoulda/context.rb:350:in `test: on DELETE to :destroy should delete the addresses phone numbers. '
2 tests, 1 assertions, 0 failures, 1 errors
rake aborted!
Command failed with status (1): [/usr/local/ruby_187/bin/ruby -I"lib:test" ...]
I think the key mystery is why it can't find the Address with that ID.
Another factor is that when I comment out this block, the remaining test passes.
should 'delete the addresses phone numbers' do
assert PhoneNumber.find(:all, :conditions => {
:id => phone_numbers(:mary_publics_phone_number).id
} ).blank?
end
Anyone seen this before?
Troubleshooting suggestions?
One thing to realize about Hashes in Ruby is that they don't retain ordering. I've had problems before that change the hash ordering depending on what code is loaded in memory -- even adding a puts "foo" somewhere would make a bug go away because I didn't realize the ordering of the Hash made a difference somewhere deep in the code. (Note: Hash does retain ordering in 1.9.1, specificly because of problems like that, if I were to guess.) This is consistent with what you say about how commenting out code makes other code pass. Since most fixtures are read in using YAML as Hashes, it's reasonable to think this might be a cause. Finding someplace that Hash ordering (i.e. in something like each) makes a difference may or may not make sense in your case. If nothing else, it's something to keep in mind.
Have you tried using Fixtures.identify(:mary_publics_phone_number) instead of phone_numbers(:mary_publics_phone_number).id? (See also: Fixtures documentation.) Another thing to keep in mind: you may not have unique fixture names. I'd check for duplicates, just in case. I know a lot of people who just copy and paste fixtures because they don't know about YAML's ability to give default values. In the process, they might forget to change the fixture's name. Example:
DEFAULTS: &DEFAULTS
created_on: <%= 3.weeks.ago.to_s(:db) %>
first:
name: Smurf
<<: *DEFAULTS
Another issue I've had when moving from OS X to Linux is subtle differences in the Ruby version. (Even if both report 1.8.6, keep in mind that the patchlevel matters.) It used to be the case that the Red Hat version of Ruby had a memory leak in the garbage collector that required us to restart long running processes on occasion. (Before we realized what was going on, it created some hard to find bugs as they wouldn't happen for a long time.) Since CentOS is related to Red Hat (basically the same as RHEL), I could imagine other version differences causing issues. I know OS X never had the memory leak problem I described, which made it even harder to narrow the bug down. As far as differences go between 1.8.6 and 1.8.7, you'll have to refer to the change logs. Be aware that the version of Ruby built from source and the packaged version could behave differently -- I think the memory leak problem was introduced by whoever packaged Ruby.
Those are only a few possible causes. Please report back with what you find!
I have this block of code:
users = Array.new
users << User.find(:all, :conditions => ["email like ?", "%foo%"])
users << User.find(:all, :conditions => ["name like ?", "%bar%"])
users.flatten!
users.uniq!
puts users.to_json :include => [:licenses]
When I run it using script/console, it returns exactly what you would think it should, a JSON representation of the Array of users that I found, flattened, and uniquified. But running that same line of code as part of a search_for_users method, I get this error
TypeError in ControllerName#search_for_users
wrong argument type Hash (expected Data)
and the line referenced is the line with the .to_json call.
It's baffling me because the code is verbatim the same. The only difference is that when I'm running it in the console, I'm entering the conditions manually, but in my method, I'm pulling the query from params[:query]. But, I just tried hardcoding the queries and got the same result, so I don't think that is the problem. If I remove the :include, I don't see the error, but I also don't get the data I want.
Anyone have any idea what the issue might be?
There are a few plugins and gems that can cause .to_json to fail if included in your controller. I believe that the Twitter gem is one of them (ran into a problem with this awhile back).
Do you have "include [anything]" or "require [anything]" in this controller?
If not, I'd suggest temporarily removing any plugins you're using to troubleshoot, etc.
Finally, what happens if you replace that entire controller action with simply:
%w(1 2 3 4 5).to_json
That should help you pin down what is failing.
Whenever code in tests or the console behaves different from production environment (which is a guess... you might be running your site in development mode), this calls for a load order issue. In production environment, all the models and controllers are preloaded, in other environments they are loaded lazily when needed.
Start your console with RAILS_ENV=production ./script/console and see if you can reproduce the error this way.
As cscotta mentioned, there are a couple of gems and librarys, that can interfere with .to_json, first to mention the functionality, that you get when you require 'json'. I personally ran into several issues with that.
Hope this helps
Seb