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.
Related
I updated my company's application from Rails 5.2.1 to Rails 5.2.2.1. Upon running our test suite post-update, I am encountering issues with validating uniqueness within the scope of a model, specifically, when appending a model to the ActiveRecord relation of another model. For example, in our application, if I were to do #person.cars << #car, we would run a uniqueness validation (validates :car_id, uniqueness: { scope: :group_id }. Even in a scenario where #person.cars was originally empty, our post-update branch is throwing validation errors on this uniqueness check. These test cases work on our master branch (pre-update), but not on our update branch (post-update). There have been no other changes made to the application besides updating Rails from 5.2.1 to 5.2.2.1. I am wondering if anyone knows of any existing bugs or issues in relation to Rails 5.2.2.1 uniqueness validations that may be causing this. I have looked through the changelogs of both Rails and ActiveRecord, as well as a few other dependencies that were updated, but I have been unable to find anything.
Looks like this is an issue with a change made in Rail's ActiveRecord::Associations which used to remove duplicates in version 5.2.1, when appending to an ActiveRecord association. This never threw a RecordInvalid exception, as the duplicate would be removed before hand. In 5.2.2.1, it looks like that has been removed, and any duplicates appending to an association will no longer be preemptively deleted (most likely to mimic Ruby += functionality). I had to change all your uses of += to a relation to |= to ensure duplicates were no longer being appended on.
Sorry for no being able to post any code or stack traces. The stack trace was very application specific and wouldn't have been helpful at all, and the code is proprietary. Appreciate the help!
I have some weird issues going on (for a very weird use case as I'll explain). I'm setting up a multi-tenant application using postgres schemas for data multi-tenancy.
Each company in my system will get its own schema. The way I accomplish this is with an after_commit on the model, on create, that then goes and creates a new postgres schema, and loads schema.rb into it. (copied from rake db:schema:load code) using ruby load.
You can see the gem here
Anyway, all this works (in the console). Creating a company creates the new schema and i can switch to it etc... my problem lies in my integration tests. I have an rspec test that creates to companies like so:
before do
#c1 = Factory :company
#c2 = Factory :company
end
What's odd is that I start to get the logs about the db schema loading, but they're truncated. Almost as if they're happening in parallel. Here's a sample output:
>> create: database: unique_name1
-- create_table("first_table_in_schema_rb", {:force=>true})
>> create: database: unique_name2
create: database is my log line, the -- create_table is from schema.rb itself.
As you can see, the second create: database seems to happen while I'm loading schema.rb from the first company creation.
Does anyone know if load is somehow asynchronous? I know ruby doesn't have real threads, but could it be using fibres or something? This is really messing me up because when my test comes around, the postgres schema that was meant to be created doesn't seem to exist.
Rails 3.0.8
Ruby 1.9.2
Im not 100% sure this is your problem because im sure of what happens with require but not with load, the things this happen to me once with require because require is not atomic, so loading code from a file with require will cause a race condition. Maybe that is what is happening with load but i was not able to find any info about load been atomic or not.
nevermind... issue had nothing to do with load it was the fact that i was already connected to the wrong schema when importing the schema.rb
There was in fact an exception being thrown that was silently caught somewhere
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)
I've been trying to solve a problem for a few weeks now. I am running rspec tests for my Rails app, and they are working fine except for one error that I can't seem get my head around.
I am using MySQL with the InnoDB engine.
I have set config.use_transactional_fixtures = true in spec_helper.rb
I load my test fixtures manually with the command rake spec:db:fixtures:load.
The rspec test is being written for a BackgrounDRb worker, and it is testing that a record can have its state updated (through the state_machine gem).
Here is my problem:
I have a model called Listings. The rspec test calls the update_sold_items method within a file called listing_worker.rb.
This method calls listing.sell for a particular record, which sets the listing record's 'state' column to 'sold'.
So far, this is all working fine, but when the update_sold_items method finishes, my rspec test fails here:
listing = Listing.find_by_listing_id(listing_id)
listing.state.should == "sold"
expected: "sold",
got: "current" (using ==)
I've been trying to track down why the state change is not persisting, but am pretty much lost. Here is the result of some debugging code that I placed in the update_sold_items method during the test:
pp listing.state # => "current"
listing.sell!
listing.save!
pp listing.state # => "sold"
listing.reload
pp listing.state # => "current"
I cannot understand why it saves perfectly fine, but then reverts back to the original record whenever I call reload, or Listing.find etc.
Thanks for reading this, and please ask any questions if I haven't given enough information.
Thanks for your help,
Nathan B
P.S. I don't have a problem creating new records for other classes, and testing those records. It only seems to be a problem when I am updating records that already exist in the database.
I suspect, like nathan, transaction issues. Try putting a Listing.connection.execute("COMMIT") right before your first save call to break the transaction and see what changes. That will break you out of the transaction so any additional rollback calls will be non-effectual.
Additionally, by running a "COMMIT" command, you could pause the test with a debugger and inspect the database from another client to see what's going on.
The other hypothesis, if the transaction experimentation doesn't yield any results, is that perhaps your model really isn't saving to the database. Check your query logs. (Specifically find the update query).
These kind of issues really stink! Good luck!
If you want to investigate what you have in DB while running tests you might find this helpful...
I have a rspec test where I save #user.save and it works like a charm, but then I wanted to see if it's really saved in the DB.
I opened rails console for test environment
rails c test
ran
User.all
and as expected got nothing
I ran my spec that contains:
user_attr_hash = FactoryGirl.attributes_for(:user)
#user = User.new user_attr_hash
#user.save
binding.pry
I thought that stopping the test after save would mean that it's persisted, but that's not the case. It seems that COMMIT on the connection is fired later (I have no idea when:\ )
So, as #Tim Harper suggests, you have to fire that commit yourself in the pry console:
pry(#<RSpec::Core::ExampleGroup::Nested_1>)> User.connection.execute("COMMIT")
Now, if you run User.all in your rails console you should see it ;)
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