If I try to run rails server or rails console and there are uninstalled dependencies or pending migrations, I will get an error message informing me about this.
Is there any similar Rails command that can be run for doing this check, without booting server or console?
I don't know how much you'll have to gain from checking, since you can just run the actual commands and it'll tell you the same information and take pretty much the same amount of time:
alias rs='bundle && rake db:migrate && rails s'
One thing you could do is integrate the hookup gem. It basically manages this annoyance for you whenever you change branches, automatically running bundle and rake db:migrate. It also, conveniently, rolls back migrations that are not on the branch you're changing to, which can be a pain, too. It does add a bit of a performance penalty, though, especially on larger projects.
gem install hookup
cd yourproject
hookup install
For gems it's easy enough to just run:
bundle check
For db this will show you if any migrations are pending with a "down" status:
rake db:migrate:status
or in rails 5 or higher
rails db:migrate:status #rails 5+
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
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
How do I undo bundle exec rake db:setup?
I ran it in the wrong rails app. I ran it in the blogger when I should have ran it in the blogger_advanced app.
You can do rake db:drop
.
It will drop all tables (thats any tables created by setup, any migrations run by setup and any seeds created by setup)
You may use rake db:rollback and it'll rollback migrations one by one, but if yours apps have same named models (User for example) it'll be lost. So you need to dump this tables first and recreate them later using database administrator tool.
And also it'll broke your schema_migrations table and you'll need to refill it by hands from your migration file names.
So if there is not much useful info, it's better to use #Alexphys approach.
I deployed a new feature to Engine Yard that had migrations. Of course I passed the migration flag and it worked successfully. But then I decided to take the feature out.
Note: These migrations removed some columns
I then rolled back on github and deployed again, but now I'm getting a postgres error that a column doesn't exist (this is a column removed in the migration from before)
How do you rollback migrations on Engine Yard?
TMP,
While there is a rollback command built into the engineyard gem, it would be better to just deploy with a new migration that effectively adds the columns back in or update the code to not use the missing columns.
Evan
I've discovered that when you ssh into your engineyard app you can go to the current deploy's directory and run bundle exec rake ... thus you can run probably run bundle exec rake db:rollback
I recently set up a Cedar (Rails 3.1) app on Heroku, and to run, for example, a migration, you'd do
heroku run rake db:migrate
I learned that it's good practice to use "bundle exec" before any rake command (as Katz says http://yehudakatz.com/). So, I thought perhaps the following is actually better practice:
heroku run bundle exec rake db:migrate
But to reduce verbosity, is it alright to use the former command, or is the one with bundle exec critical?
On Heroku when the slug is compiled the Gems are installed from into a clean slug as specified in your Gemfile so there's not going to be extraneous Gems floating around the place - there's no need to use bundle exec on Heroku - else I'm sure the Heroku documentation would tell you to do it.
"In some cases, running executables without bundle exec may work, if the executable happens to be installed in your system and does not pull in any gems that conflict with your bundle. However, this is unreliable and is the source of considerable pain. Even if it looks like it works, it may not work in the future or on another machine"
Quoting from bundler's Documentation