First time here, I hope do it right.
I'm following the railstutorial 3.2 and I'm in section 5.4, in the paragraph above to listing 5.32.
(In fact, you can just type rake by itself; the default behavior of rake is to
run the test suite.)
I used rake by itselft but I have a error since then. When I run:
"$ bundle exec rake spec" I get this error.
http://pastebin.com/F0wrEkT1
My database.yml is:
http://pastebin.com/tWAgeFTV
My problem is that I don't know why it is asking for production database when I didn't use it yet. And whe I look for the issue I don't find topics about (almost I didn't find it).
Do you have some clues to star looking or to know what is happening?
Thanks a lot.
I'm not sure why it is looking for the production DB but you may want to skip ahead. Just read a little further:
(In fact, you can just type rake by itself; the default behavior of rake is to run the test suite.) The only caveat is that using rake to run the tests for the current sample application will raise an error since it requires the test database to be prepared properly, a step we’ll defer to Section 6.2.1.
It recommends running:
bundle exec rake db:test:prepare
Related
What is the difference between commands rake and rails in Ruby?
Which one is faster and why?
The difference is in what binary is being called.
If you were to call bundle exec which rake within your Rails app root directory, you'd get something like /home/[USERNAME]/.rbenv/versions/2.5.5/bin/rake and for bundle exec which rails, you'd get /home/[USERNAME]/.rbenv/versions/2.5.5/bin/rails. From there you can cat (cat /home/[USERNAME]/.rbenv/versions/2.5.5/bin/rake) both these paths and see similar code is being ran for each, but the end of the files is different.
rails
gem "railties", version
load Gem.bin_path("railties", "rails", version)
rake
gem "rake", version
load Gem.bin_path("rake", "rake", version)
Here they're both calling load on Gem.bin_path but with different arguments, which are attempting to load separate gems in. You can follow the code further by running a irb/pry/rails console, and setting up the needed require 'rubygems' and version = ">= 0.a", then run Gem.bin_path("railties", "rails", version) and Gem.bin_path("rake", "rake", version) to see what the load is actually trying to run. I'll admit it'll become a bit of a rabbit hole before you come across the logic that eventually ends up identifying a rake task argument passed to rails and it proxy's it to Rake and stop there and defer to this SO answer for the rest.
When rails is ran and passed arguments which were intended to be ran by rake, it will attempt to first find if it was an actual argument intended to be given to the rails command, determine that it wasn't, then attempt to run it as a rake command for you for overall naming simplicity added in by the Rails team in Rails v4.
So which is faster to run? rake for actual rake tasks, as it'll bypass the extra logic in needing to determine it was being passed rake arguments. But also rails specific arguments cannot be ran with rake e.g. bundle exec rake generate will not work (unless you have a generate task). If in doubt, run bundle exec rails --help and in at least Rails v5, it'll output which arguments are rails specific and which are rake specific.
rake is a Make-like program implemented in Ruby.
rails is a web framework, which also has some rake tasks.
This means that you can have a ruby program with rake but without rails, but not the other way around.
By itself, rake will be faster because you don't need to load the whole rails application.
But when launching a rake task, it can have dependencies, for example the :environment dependency in a rails app, which tells rake to load the rails environment and quite a bit of your application depending on the current environment.
In this case, the initialization of a rake task may take as long as a rails command.
Please note that the actual task run needs also to be taken into account, it can be very short or take several minutes.
For example, rake db:migrate, which is a rails task available by default, runs the migrations on the database, which can be time-consuming if the database is already populated and/or you have a lot of migrations
Here is a very strange issue I have on my new computer setup (otherwise, it's working on my other setups).
I'm running : rake db:migrate
No errors, but it does nothing...
rake db:migrate:status show me the list of pendings migrations (marked as "down"), the ones that I effectively have in my bd/migrate folder.
Even if I run those commands or removing files in db/* manually, db:migrate is still useless.
rake db:drop:all
rake db:create
rake db:migrate
I have tried also db:reset, db:rollback STEP=1000.
If I specify a VERSION number (one from the list given by db:migrate:status) as:
rake db:migrate VERSION=20150106184930
I've got the following error:
No migration with version number 20150106184930
I have also generated a new migration with:
rails generate migration TestMigration
And again, db:migrate completely ignor it.
My current setup is: windows7, rails 4.2.0, rake 10.3.2.
Thanks for any help, clues...
After hours of deep debugging in rake, reinstalled all my complete setup, I finally figured out that the problem was comming from the "non so special" characters [ or ] somewere in my project path!!
DAMN RAILS!
Due to readability, all my project's folders start with "[NAME-OF-PROJECT]xxxx/"... then in this particular rails project comes a subfolder for the rails app.
No error, nothing that point you out that the path name could be the issue. I'm quite sur that "[" and "]" are not forbidden character (even on linux) : http://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words
And why "[" or "]" makes rake db:migrate failing and not rake db:migrate:status???
For me it clearly shows some weakness in rails architecture. I should probably do a bug report for that... can someone point me some report mailing list or whatever?
I hope that my misadventure will save hours for others.
If this is a new rails setup, you may not have gems on your system, but only in your app. Try prepending bundle exec to your rake commands.
bundle exec rake db:migrate
Try run gem update and try rake db:migrate again.
I'm going through Mhartl's tutorial and I'm sporadically getting this error when I run tests in the sublime text 2 console. If I use bundle exec rspec/rspec in the the terminal it works fine, but it's not the case when call shortcut commands in sublime text to run tests. I don't know if it makes a difference but I'm also running guard
Users/User/.rvm/gems/ruby-2.0.0-p247#global/gems/bundler-1.3.5/lib/bundler/runtime.rb:33:in `block in setup': You have already activated rspec-core 2.14.5, but your Gemfile requires rspec-core 2.13.1. Using bundle exec may solve this. (Gem::LoadError)
I tried searching stack overflow for solutions and tried bundle exec rake db:migrate(I normally don't specify bundle exec) as well as bundle exec rake test:prepare. Neither of which work.
I'd appreciate not only an answer to the problem but perhaps a more in-depth answer of when to use rake db:migrate and rake test:prepare. I know their main uses, but there are perhaps some less obvious times where i would need to run it. SPecifically, for this problem I would have thought rake test:prepare would be relevant and I'm still not sure what effect rake db:migrate has on the testing suite/rspec part of the application
To answer part of your question, you can delete unused gems through bundle clean, although when I've had multiple versions of gems, I've found that I had to use bundle clean --force which may mean that I had "system gems" coming into play, per https://stackoverflow.com/a/10190608/1008891.
I created a new engine in Rails 3.1.3 and apparently there's that rake task that copies over all migrations. I tried following rake abc:install:migrations which threw:
rake aborted!
Don't know how to build task 'abc:install:migrations'
(See full trace by running task with --trace)
I also tried rake abc_engine:install:migrations with the same result.
Then I read bundle exec rake railties:install:migrations or bundle exec rake railties:install:migrations FROM=abc_engine should do the trick too but no success. Nothing was copied even though no error was thrown.
My migrations are located in db/migrate/ within the engine folder and I ran all commands above from spec/dummy/
Does anyone know how to use this new rake task in order to copy migrations from the engine?
I ran this instead:
rake railties:install:migrations
And my migrations were copied from the engine.
Hope this helps.
I finally got found/got lucky with my (similar) issue. For the first error, it just disappeared, not sure why. Then I figured out that I didn't created the migrations using the usual file name format, so the ActiveRecord::Migrator.migrations method was ignoring them.
If the app you're mounting the engine to doesn't already have ActiveRecord (i.e. you're introducing ActiveRecord to your host app for the first time by mounting the engine), you can get this error as well. Specifically, you'll get this error if you don't have require "active_record/railtie" in your application.rb, or if it's commented out. That line is what enables the rake railties:install:migrations task, which is defined here. rake railties:install:migrations is, in turn, called by the rake abc_engine:install:migrations task here.
Tl;dr: try adding require "active_record/railtie" to your application.rb if it's not already there.
I pushed an update to my Rails app production server, and in the update there was a new database migration. I ran rake db:migrate and got the common error seen here. I ran the rake again in bundle exec bash and it was successful. But after restarting my apache server, I'm now getting the 500 Error page. This update worked fine on my localhost, and was mostly this update to the db with supporting changes in the according view and controller/routing.
I don't even know why this error appeared this time, as I have pushed db updates successfully before using only rake. Nonetheless, the rake was successful. The 500 error page only shows on pages that require that specific new ActiveRecord. Any ideas on how to debug?
EDIT: My problem was an extremely simple one. I merely forgot to include the environment with the rake:
bundle exec rake db:migrate RAILS_ENV=production
Unfortunately, it took quite a while to narrow that down, as I couldn't use IRB to check the db entries until I followed these steps.
Did you run rake db:migrate on your server? Also be sure to set the RAILS_ENV flag so your production database is updated:
rake db:migrate RAILS_ENV=production