I have some code which I run from an initializer and it works fine. (It saves default settings from a yaml file to the database for the rails-settings-cache gem.)
But when I run this on Travis CI, since it is doing a migration from scratch, the initializer fails because the table does not exist yet.
Is there a way of running code after the migration but before the application starts?
So while I don't love doing this, an easy way to prevent the initializer from running during db:migrate, but running on application start or test run is to wrap it in a clause testing if the table exists. So if you take your existing initializer code and wrap it in
if ActiveRecord::Base.connection.table_exists? 'table_name'
....
end
where 'table_name' is the name of the missing table, then both rake db:migrate and the spec run should be able to complete successfully.
Related
I am working through the Michael Hartl tutorial
I have created a migration file called add_remember_token_to_users and filled it with the contents from listing 8.16 in order to create a remember_token cell, which is indexed, for each user.
I migrated the data, from the command line, which, according to the cmd, ran successfully. However, I am looking at the test.sqlite3 file with a splite browser and it has not updated to include a remember_token cell. What is going on?
I don't see any typos in my migration file and I generated the migration file using rails.
You need to apply the migration to the test database as well, because the migration only updated the development database. You can achieve it using the following command:
rake db:test:clone_structure # Recreate the test databases from the development structure
Note that there are other ways to achieve the same results such as running just the clone if you are wondering:
db:test:clone
I am trying to create all my tables from schema.rb
I used the command: "rake db:schema:load"
However, this fails because in one of my initializers, it is referencing a model/table that obviously doesn't exist (since the database is empty)
I could comment out these lines, and then run schema:load again, but is there an alternative?
Probably the fastest way is to just move the offending initializer to a temporary directory that is outside of the app, and then run your schema load. But if that doesn't work, or isn't an option for some reason, you could always work around that by creating a bare bones rails app to do the schema load:
Create a new rails app: rails new (app)-fixer
Copy your gemfile (unless there are specific exceptions) to the fixer app.
Copy your database.yml config to the fixer app.
Copy your schema.rb file to the fixer app.
Do all appropriate "bundle install" commands as needed for your app.
Then run "rake db:drop db:create db:schema:load"
That will build up a new database from scratch, based on your current schema.
You can add a check for the table existance in your initializer.
if TheModel.table_exists?
// do something with the model
end
I'm trying to create a migration for my app, and in this app I'm using a gem that tries to startup a different service upon app startup. Apparently, creating a migration...
rails generate migration AddSomeStuffToTable stuff:string
...activates the app, and this gem which tries to connect to startup the service. It appears that starting up the app via generating a migration makes the service startup unable to connect, so it just keeps sleeping and trying again, never actually running the migration.
In this gem, I've already dealt with this for rake, so this is what I've got so far:
MyService.start unless defined? Rake or defined? IRB
This handles the rake problem (like rake db:migrate, rake db:populate), but how can I handle the creation of migration, which (as far as I know) is not a Rake task?
You could try using environment variables for disabling the service:
MyService.start unless ENV['NO_SERVICE']
And run your command like this:
NO_SERVICE=1 rails generate migration AddSomeStuffToTable stuff:string
However, I doubt this scales well, especially if multiple developers are in the app. A better approach might be to do the reverse of this, to only start the service if a particular env variable is present. However, going this direction, you'd need to make sure your app servers set this variable, for example:
Apache: SetEnv START_SERVICE 1
nginx: env START_SERVICE=1
thin: START_SERVICE=1 thin start
I wonder how to setup testing in my rails apps. When I run rake test, first thing odd, it launch a bunch of CREATE TABLE against my dev. database (hum.. do not like this..). So I launch rake test RAILS_ENV=test and I even try bundle exec rake test RAILS_ENV=test. Now, the CREATE TABLE is against my test database but all fails with this error :
** Execute test:units
test/unit/category_test.rb:5:in `test': unknown command 't' (ArgumentError)
from test/unit/category_test.rb:5:in `<class:CategoryTest>'
I have used basic generator in Rails 3 and do not change anything. So I have this in caterogy_test.rb :
require 'test_helper'
class CategoryTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
I use Rails 3.0.7 and basic config.
Any ideas ?
EDIT
I am becoming crazy, made a lot of tries, neither seems to work. When I start a new application with a few things, rake test works fine but when I try this on my current one, it launch always against my dev. db and do not work at all. I have tried to edit the test files, to revert them back, try to remove/setup test db with different ways, try different rake version, compare a lot of things on one side my current application and on the other a brand new one... Found nothing.. Help !
EDIT 2
Sounds lame, but is it normal that rake does the same thing than rake test ?
EDIT 3
Sounds odds, while I continue to work on what's wrong, I realize that every-time I run rake test, it does stuff on the dev environment and not the test one (watching the logs). It does this on my computer OSX and on our server FreeBSD for all the Rails 3.0.7 apps. Are you sure rake test is supposed to work on the test environment by default ?
EDIT 4
Please help!
EDIT 5 - SUMMARY
When running rake test in my computer or on our server in Rails 3.0.7 with different apps it does the following :
run CREATE TABLE and INSERT INTO migration against the dev. db.
do not empty the dev. db.
development.log gets written not the test.log
also an issue with the error unknowm comman 't' with one specific app.
EDIT 6 - db config
Nothing change from the default yet : https://gist.github.com/1006199
EDIT 7
rake db:test:prepare --trace -> nothing break (but keep printing (first_time)
https://gist.github.com/1007340
With RAILS_ENV="test" for rake, everything goes fine. It write on the test logs.
ruby -I test test/unit/category_test.rb same erros than with rake, but no write on the dev. or test logs.
a bunch of unorderd answers:
the "CREATE TABLE" statements usually means that your test_db is created from scratch (by default, before test task, a db:migrate is launched). are you sure they're called on dev_db?
also check your config/database.yml to see if there's some typo (eg: using same table for test and dev environments)
it looks like there's an error in some of your migration files (that 't' error remember blocks in migrations).
"rake test" is the default task, that's why it's run when you just launch "rake" without arguments.
EDIT:
according on what I see on edits, from 5 and above, it looks like you have some issue with environment files. so try to double-check:
* config/environments/test.rb
* config/application.rb
* config/environment.rb
if with RAILS_ENV="test", everything goes fine, then I'm almost sure you have changed some default behaviour in your app (configs, env variables, any particular gem?)
also, in your test/test_helper.rb, add RAILS_ENV='test' at the beginning of file, this should force test environment.
I had that same error message, except to me it said: in `test': unknown command 'i' (ArgumentError).
The 'fix' or 'workaround' was to simply use:
$> bundle exec rake test
instead of using 'rake test'
After significant troubleshooting, I figured out that I needed to run rake spec once (I can abort with control-c) before I can run rspec directly (e.g. on a subset of our specs). We are running Rails 3.0.7 and RSpec 2.5.0.
Clearly, rake is running some important database setup tasks / code (we have custom code in the root level rails Rakefile and possibly other places).
How can I run the rake test database setup tasks / code without running rake spec?
In addition to being able to run rspec on a subset of files, I am using specjour to spread our specs across multiple cores (haven't had success with spreading them across the LAN yet), but I see the same behavior as for running rspec directly: I need to run rake spec on each test database (assuming two cores) before specjour works:
rake spec TEST_ENV_NUMBER=1
control-c (after tests start)
rake spec TEST_ENV_NUMBER=2
control-c (after tests start)
specjour
Note: my config/database.yml has this entry for test (as is common for the parallel testing gems):
test:
adapter: postgresql
encoding: unicode
database: test<%=ENV['TEST_ENV_NUMBER']%>
username: user
password:
parallel_tests seems to set up its databases correctly, but many of our specs fail.
I should also mention that running specjour prepare causes Postgres to log errors that it can't find the databases, but it creates them (without tables). On a subsequent run, no errors are logged, but also no tables are created. It is possible that my whole issue is simply a bug in prepare, so I reported it on github.
I think that I can run arbitrary code on each specjour test database by setting Specjour::Configuration.prepare in .specjour/hooks.rb, so if there's any rake tasks or other code that I need to run, it may work there.
I would recommend dropping your test database, then re-create it and migrate:
bundle exec rake db:drop RAILS_ENV=test
bundle exec rake db:create RAILS_ENV=test
bundle exec rake db:schema:load RAILS_ENV=test
After these steps you can run your specs:
bundle exec rspec spec
gerry3 noted that:
A simpler solution is to just run rake db:test:prepare
However, if you're using PostgreSQL this wont work because the rails environment gets loaded, which opens a database connection. This causes the prepare call to fail, because the DB cannot be dropped. Tricky thing.
I had a similar problem setting up the CI system at work, so I gradually worked up a system to handle this. It may not be the best solution, but it works for me in my situation and I'm always on the lookout for better ways to do things.
I have a test database that I needed setup, but also needed seeded data loaded for our tests to work.
The basics of troubleshooting rake tasks is to run rake with the --trace option to see what is happening under the hood. When i did this, I found that running rake spec did a number of things that I could replicate (or modify as I saw fit) in a custom rake task.
Here's an example of what we do.
desc "Setup test database - drops, loads schema, migrates and seeds the test db"
task :test_db_setup => [:pre_reqs] do
Rails.env = ENV['RAILS_ENV'] = 'test'
Rake::Task['db:drop'].invoke
Rake::Task['db:create'].invoke
result = capture_stdout { Rake::Task['db:schema:load'].invoke }
File.open(File.join(ENV['CC_BUILD_ARTIFACTS'] || 'log', 'schema-load.log'), 'w') { |f| f.write(result) }
Rake::Task['db:seed:load'].invoke
ActiveRecord::Base.establish_connection
Rake::Task['db:migrate'].invoke
end
This is only an example, and specific to our situation, so you'll need to figure out what needs to be done to get your test db setup, but it is quite easy to determine using the --trace option of rake.
Additionally, if you find the test setup is taking too long (as it does in our case), you can also dump the database into .sql format and have the test database pipe it directly into mysql to load. We save several minutes off the test db setup that way. I don't show that here because it complicates things substantially -- it needs to be generated properly without getting stale, etc.
HTH
The provided solutions all require to load the Rails environment, which is, in most cases, not the desired behaviour due to very large overhead and very low speed. DatabaseCleaner gem is also rather slow, and it adds another dependency to your app.
After months of chagrin and vexation thanks to reasons vide supra, I have finally found the following solution to be exactly what I need. It's nice, simple and fast. In spec_helper.rb:
config.after :all do
ActiveRecord::Base.subclasses.each(&:delete_all)
end
The best part about this is: It will only clear those tables that you have effectively touched (untouched Models will not be loaded and thus not appear in subclasses, also the reason why this doesn't work before tests). Also, it executes after the tests, so the (hopefully) green dots will appear right away.
The only downside to this is that if you have a dirty database before running tests, it will not be cleaned. But I doubt that is a major issue, since the test database is usually not touched from outside tests.
Edit
Seeing as this answer has gained some popularity, I wanted to edit it for completeness: if you want to clear all tables, even the ones not touched, you should be able to do something like the "hacks" below.
Hack 1 - pre-loading all models for subclasses method
Evaluate this before calling subclasses:
Dir[Rails.root.join("app", "models", "**", "*.rb")].each(&method(:require))
Note that this method may take some time!
Hack 2 - manually truncating the tables
ActiveRecord::Base.connection.tables.keep_if{ |x| x != 'schema_migrations' }
will get you all table names, with those you can do something like:
case ActiveRecord::Base.configurations[Rails.env]["adapter"]
when /^mysql/, /^postgresql/
ActiveRecord::Base.connection.execute("TRUNCATE #{table_name}")
when /^sqlite/
ActiveRecord::Base.connection.execute("DELETE FROM #{table_name}")
ActiveRecord::Base.connection.execute("DELETE FROM sqlite_sequence where name='#{table_name}'")
end
It appears that in Rails 4.1+, the best solution is simply to add ActiveRecord::Migration.maintain_test_schema! in your rails_helper after require 'rspec/rails'.
i.e. you don't have to worry about having to prepare the database anymore.
https://relishapp.com/rspec/rspec-rails/docs/upgrade#pending-migration-checks
In a spring-ified Rails 4 app, my bin/setup is usually augmented to contain
puts "\n== Preparing test database =="
system "RAILS_ENV=test bin/rake db:setup"
This is very similar to leviathan's answer, plus seeding the test DB, as
rake db:setup # Create the database, load the schema, and initialize with the seed data
(use db:reset to also drop the database first)
As the comment mentions, if we want to drop the DB first, rake db:reset does just that.
I also find that this provides more feedback when compared to rake db:test:prepare.
I started by dropping my test database
rake db:drop RAILS_ENV=test
when trying to create a new test database I ran into an issue because my user account was not the same as the account that owns the databases so I created the database in PostgreSQL instead.
type psql in the command prompt and then run the below to create a test database that uses an account other than your own.
CREATE DATABASE your_database_name OWNER your_db_owner;
then run your migrations in the test environment.
rake db:migrate RAILS_ENV=test