When i try and preform a rake I get the following. I've tried a few fixed like imploding and reinstalling my rvm - ruby (v1.9.3-p125) but nothing seems to be working. Any ideas?
rake db:seed --trace
** Invoke db:seed (first_time)
** Execute db:seed
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:abort_if_pending_migrations
rake aborted!
stack level too deep
/Users/rm/.rvm/gems/ruby-1.9.3-p125#global/gems/rake-0.9.2.2/lib/rake/task.rb:162
Tasks: TOP => db:seed
if I try and run a rake db:reset --trace
-- initialize_schema_migrations_table()
-> 0.0025s
-- assume_migrated_upto_version(20120803181844, ["/Users/rossmcnairn/rails/search/db/migrate"])
-> 0.0218s
** Invoke db:structure:load_if_sql (first_time)
** Invoke db:create
** Execute db:structure:load_if_sql
** Invoke db:seed (first_time)
** Execute db:seed
** Invoke db:abort_if_pending_migrations (first_time)
** Invoke environment
** Execute db:abort_if_pending_migrations
rake aborted!
stack level too deep
/Users/rossmcnairn/.rvm/gems/ruby-1.9.3-p125#global/gems/rake-0.9.2.2/lib/rake/task.rb:162
Tasks: TOP => db:setup => db:seed
Ive checked that my bundle exec version and my regular rake versions match.
rake --version
rake, version 0.9.2.2
bundle exec rake --version
rake, version 0.9.2.2
Any help would be greatly appreciated!
Updating OSX is known to give issues in rubies, you should recompile all your rubies:
chown -R $USER: $rvm_path
rvm get head
rvm reinstall 1.9.3-p125
rvm all-gesmsets do rvm gemset pristine
Also note that any other compiled stuff like libraries needs recompilation, this includes homebrew, macports, rvm pkg and any packages you have compiled manually.
** Execute db:abort_if_pending_migrations
rake aborted!
Did you try to run your migrations?
This may be obvious but it took me a few hours. I unwittingly created a class method for the model called create, which is the same as ActiveRecord create. So my seed file has circular reference.
I just kept staring at the seed file and wonder why I get the error while I was able to run it twice before (before adding the class method). Moral of the story: naming is important.
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 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.
Using rails 3.1.1 for windows with railsinstaller
>rake db:migrate
after a pause, brings me right back to the command line. No errors, no messages, just right back to the command line.
I tried
>rake --trace db:migrate
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config (first_time)
** Invoke rails_env (first_time)
** Execute rails_env
** Execute db:load_config
** Execute db:migrate
** Invoke db:schema:dump (first_time)
** Invoke environment
** Invoke db:load_config
** Execute db:schema:dump
Doesn't look like anything is wrong, but obviously something isn't working right.
Can anyone help?
If there are no migrations to be run, there will be no output. The --trace command outputs the various steps that rake goes through to prepare, execute, and clean up after the migration. However, when it sees that there is no migration to be run, then it doesn't actually make any DB changes. Only DB changes cause additional output.
The only difference between this and a migration is that the changes to the DB will be output to the command line. No changes => no output.
Make sure you are in the right folder (maybe in the right branch, when using git) and make sure that you have created a migration file.
rails generate migration MigrationName
Edit the generated file as you wish.
I'm unable to get rake precompile tasks running with Rails 3.1.3. I get the following error:
$ rake assets:precompile --trace
** Invoke assets:precompile (first_time)
** Execute assets:precompile
/Users/tristankromer/.rvm/rubies/ruby-1.9.2-p290/bin/ruby /Users/tristankromer/.rvm/gems/ruby-1.9.2-p290#toomanyninjas/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets --trace
** Invoke assets:precompile:all (first_time)
** Execute assets:precompile:all
** Invoke assets:precompile:primary (first_time)
** Invoke assets:environment (first_time)
** Execute assets:environment
rake aborted!
Application has been already initialized.
/Users/tristankromer/.rvm/gems/ruby-1.9.2-p290#toomanyninjas/gems/railties-3.1.3/lib/rails/application.rb:95:in `initialize!'
Same thing happens when I used bundle exec or when I deploy to heroku cedar stack.
Not quite sure where to start on this one. Any ideas?
UPDATE: I'm having issues with every rake task:
rake aborted!
Application has been already initialized.
/Users/tristankromer/.rvm/gems/ruby-1.8.7-p249#joke-off/gems/railties-3.1.3/lib/rails/application.rb:95:in `initialize!'
Upgrading rake to 0.9.2.2 and using ruby 1.9.2-p290 seems to have fixed the issue.
I had this issue, I didn't want to upgrade ruby, and what ended up working for me was the renaming config.ru in RAILS_ROOT to config.ru.bak
http://code.google.com/p/phusion-passenger/issues/detail?id=109
I came across this after realizing I was having an issue getting Passenger to recognize the "RailsEnv" setting my my virtual hosts conf
I had this problem on Rails 3.2.6
The reason it was happening had to do with a path linked gem having a bundle folder. in my gemfile
like so:
gem 'some-gem', :path => "vendor/some-gem"
In order to fix the issue I just moved the bundle folder out of the path linked gem.
mv vendor/some-gem/bundle ~
Once the bundle file was gone it worked perfectly
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?