I'm trying to run a migration on my Rails app, by using rake:db migrate --trace and I get the following output:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
It then doesn't do anything after this. If I Ctrl + C I get some errors, but I'm not sure I understand them. Is there any way I can step through and debug the migration process so I can see when it hits the problem migration?
its (space between rake and db).
rake db:migrate
try for a overview of rake db tasks:
rake -T db
Try
bundle exec rake db:migrate --trace
I realized the reason this was not firing was it was initializing a sleep command waiting on something that wouldn't be initialized via rake (the app had to be running). So, rake was not the culprit this time!
Related
I've recently updated an old application to from 3.2.13 to 4.2.10. I've got the application running in development mode but any rake or rails commands I try to run just hang/freeze. The terminal window will hang for a second and then nothing, I'm unable to even stop the process with ctrl-c. I've read a lot about running 'spring stop' to fix this but I don't have spring installed on this app.
Running the commands with --trace aren't particularly helpful.
rails generate model Foo --trace gives me nothing and rake db:migrate --trace gives me:
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
before freezing. Any pointers in the right direction would be appreciated.
I have a strange problem with rails migrations.
My db/migrate folder contains migration files and all worked fine.
But a few moment ago, I created a new file using rails g migration MigrationName, it generated a new file. then when i had runned rake db:migrate it rollbacks all and my schema version became 0.
Now when i run rake db:migrate it does nothing whereas db/migrate contains all my migrations.
i tried rake db:reset db:drop db:create db:migrate but no migrations was performed. However it says "migrations are pending run rake db:migrate RAILS_ENV=development" what i've done in vain.
I'm confused. Is anyone ever had this problem?
i've just tried RAILS_ENV=development rake db:migrate --trace and it returns:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:migrate
** Invoke db:_dump (first_time)
** Execute db:_dump
** Invoke db:schema:dump (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:dump
Running:
rake db:migrate:status
gives me:
database: database_development
Status Migration ID Migration Name
--------------------------------------------------
up 000 ********** NO FILE **********
down 20150613120151 Devise create users
down 20150613120734 Devise create admins
down 20150614114949 Create gender
down 20150614115642 Create events
down 20150614142610 Create multi events
I tried so many things:
- i dropped my database, restarted postgresql and run again rake db:setup db:migrate. rake db:migrate:status tells me that migrations are pending but it wont migrate.
it makes me crazy...
EDIT
I manually updated schema_migrations in database adding the timestamps
schema:load worked, but when i run rake db:migrate to check if its all good, it rolledback..
EDIT
if i manually fill schema_migrations version in database with timestamps, when i do rake db:schema:status they are all to up and my new migration to down, but if i do rake db:migrate it tries to revert as if i wanted to run rake db:rollback
So i fixed my issue.
In fact, i'm using dotenv to manage environment vars for development, and in my .env file i defined a var called VERSION to describe the API version...
That is the bug !
When i removed it, rake was able to migrate as expected.
I am not sure this will work for, but can you please try the following things,
First, drop tables
rake db:drop
Second, Delete/Remove db/schema.rb file
Third, create database
rake db:create
Fourth, run migration again
rake db:migrate
Please let me know if this help you a bit, good luck :)
I have a script/cibuild script, which I run on Semaphore Hosted CI Service), that contains…
time bundle exec rake db:setup db:test:prepare --trace; echo
… to setup the database and check if are there any pending migrations, but for some reason this won’t work not even on my development machine.
Striping down script/cibuild’s contents boils down to this:
export RAILS_ENV=test
export RACK_ENV=test
# options to rake 'spec' task
export SPEC_OPTS='--color --format documentation --backtrace spec'
echo "Installing dependencies..."
time bundle install --deployment; echo
echo "Setting-up database..."
time bundle exec rake db:setup db:test:prepare --trace; echo
echo "Running tests..."
time bundle exec rake spec --trace; echo
Build will eventually fail with the following trace on Semaphore:
Running tests...
** Invoke spec (first_time)
** Invoke test:prepare (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:abort_if_pending_migrations
You have 10 pending migrations:
20130418144736 CreateUsers
20130424134725 CreateCollections
20130506124127 AddStaffToUsers
20130513115848 CreateResourceTypes
20130513140804 InstallHstore
20130513141924 CreateResources
20130513144332 AddCredentialDataToUsers
20130523155851 RenameSubscriptionDataInResource
20130531110125 AddProfilePictureToUser
20130722101545 AddEmailIndexToUser
Run `rake db:migrate` to update your database then try again.
Now it seems to me that the problem may not be at db:setup db:test:prepare line, but instead when rake spec is run. I am not sure.
In any case if I run in my development machine…
rake db:drop:all
rake db:setup db:test:prepare
… I will end up with an empty test database (“empty” as in no tables, etc.) whereas…
rake db:drop:all
rake db:setup
rake db:test:prepare
… will create also test database, as expected.
One might think as if I didn’t run rake db:migrate at some point (hence 10 pending migrations), but I am pretty confident that this isn’t the case. Although I don’t have a db/schema.rb file, rails should apply all the migrations to get to the final database schema just fine.
Any ideas, please? Thank you.
Update:
I kind of suspect that the issue might be related to setting RACK_ENV and/or RAILS_ENV environment variables to test. This seems to mess things up a bit.
I want to start my workers when I start my development server to test the a new cron job I have in my resque scheduler, so I run this command when starting dev server-
QUEUE=* rake environment resque:work rails s
it has worked for me before and if I'm reading their documentation correctly should still work.
But I'm getting the following error after I interrupt it after it gets hung up-
^Crake aborted!
Don't know how to build task 'rails'
here is what I get after keyboard interrupt and running it with --trace
** Invoke environment (first_time)
** Execute environment
** Invoke resque:work (first_time)
** Invoke resque:preload (first_time)
** Invoke resque:setup (first_time)
** Invoke environment
** Execute resque:setup
** Execute resque:preload
** Invoke resque:setup
** Execute resque:work
^Crake aborted!
Don't know how to build task 'rails'
I don't understand why I would be getting the error and additionally why it previously loaded and worked but not anymore. What am I missing here?
Are you sure that you manage to run this command sometime back successfully
QUEUE=* rake environment resque:work rails s
because the way I know rails s is a list of rails command not a rake task
you can run consecutive rake separating spaces like
QUEUE=* rake environment rake1 rake2 rake3
but you cant run a rake and rails command they way you mention above
what I see from your trace above that rake(resque rake) is running now instead of passing a second rake you specified a rails command to start the server rake is considering that as rake task (which is not true)
I believe you are looking for this
QUEUE=* rake environment resque:work && rails s
But I dont believe that what you have mention would ever work please let me know if something conflict over here
Hope It make sense
This is better:
BACKGROUND=yes QUEUE=* PIDFILE=./tmp/resque.pid bundle exec rake environment resque:work
Then:
rails s
If you need stop resque worker:
kill -QUIT $(cat ./tmp/resque.pid)
Just wondering if there's a way to run Rails tests without dropping the database. I'm currently only executing unit tests and am using the following rake command to do so: rake test:units.
Thanks for the help in advance!
Just in case this is relevant:
Rails 3
Ruby 1.8.7 (MRI)
Oracle 11g Database
activerecord-oracle_enhanced-adapter
In Rails 5 (and possibly earlier versions), just comment-out the following line in spec/rails_helper.rb:
ActiveRecord::Migration.maintain_test_schema!
This will prevent rake test or rspec from attempting to drop your test DB. You'll need to run migrations manually as well.
For Rails 5.2 this behaviour can be modified setting maintain_test_schema to false in test/test_helper.rb before importing rails/test_help:
ActiveRecord::Base.maintain_test_schema = false
require "rails/test_help"
rails/test_help will check the value of maintain_test_schema to decide if it has to drop/create/migrate the test database or not.
After doing some research, I have found that there isn't a way to do this. The test rake tasks will always drop the database, even when providing the TEST= option as Bohdan suggests.
By using the --trace option, this can be proven. Here is the output:
$ rake test:units TEST=test/unit/post_test.rb --trace
(in /Users/johnnyicon/Development/ror/test-app)
** Invoke test:units (first_time)
** Invoke test:prepare (first_time)
** Invoke db:test:prepare (first_time)
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
** Execute db:test:prepare
** Invoke db:test:load (first_time)
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:load
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
** Execute test:prepare
** Execute test:units
Reading through the Ruby on Rails Guides for Testing, it describes what some of these rake tasks mean. The one to pay particular attention to is the db:test:load task, which you see on the 7th line from the bottom of the output as ** Execute db:test:load. The guides say the following about this task:
Recreate the test database from the
current schema.rb
So even if I were to execute the unit tests one by one as Bohdan suggests, the rake task would still recreate the database. Not the answer I was hoping for, but it isn't a problem anymore.
The reason I was asking to begin with was because I did not have access to another database to use for testing, so I was using my development database for testing as well. But since then, I've been able to get another database dedicated for testing.
Thanks anyway Bohdan! I appreciate the help!
This is a rather old post that does the monkey patching of overriding purge/load tasks:
http://www.pervasivecode.com/blog/2007/09/22/making-rails-raketest-not-drop-your-pgsql-database/
For those looking for a way to skip Rails' default behavior, try adding this to your Rakefile:
Rake::Task["db:test:prepare"].clear
Rake::Task["db:test:load"].clear
Rake::Task["db:test:purge"].clear
Could you not write a custom Rake task that monkey patched the Rake db:test:load task to do nothing?