Why Does First Deploy with Capistrano Run db:migrate?

Question

I'm using Capistrano to deploy to production for the first time, and I'm getting an error when I run

cap production deploy

The error is:

** Invoke deploy:migrate (first_time)
** Invoke deploy:set_rails_env
** Execute deploy:migrate
DEBUG [048f89c6] Running /usr/bin/env if test ! -d /home/deployer_user/apps/ap_production/releases/20140209005208; then echo "Directory does not exist '/home/deployer_user/apps/ap_production/releases/20140209005208'" 1>&2; false; fi on eslope.net
DEBUG [048f89c6] Command: if test ! -d /home/deployer_user/apps/ap_production/releases/20140209005208; then echo "Directory does not exist '/home/deployer_user/apps/ap_production/releases/20140209005208'" 1>&2; false; fi
DEBUG [048f89c6] Finished in 0.160 seconds with exit status 0 (successful).
INFO [52f75214] Running ~/.rbenv/bin/rbenv exec bundle exec rake db:migrate on eserver.net
DEBUG [52f75214] Command: cd /home/deployer_user/apps/ap_production/releases/20140209005208 && ( RBENV_ROOT=~/.rbenv RBENV_VERSION=2.1.0 RAILS_ENV=production ~/.rbenv/bin/rbenv exec bundle exec rake db:migrate )
DEBUG [52f75214]    rake aborted!
DEBUG [52f75214]    An error has occurred, this and all later migrations canceled:
DEBUG [52f75214]    
DEBUG [52f75214]    PG::UndefinedTable: ERROR:  relation "client_infos" does not exist
DEBUG [52f75214]    : ALTER TABLE "client_infos" RENAME TO "clients

The error actually makes complete sense. The referenced table doesn't exist. What I don't understand is why the migration is running at all? Why isn't the the database just being created from the schema on the first run. Did I inadvertently remove a file that says what migrations have been run? Either by just deleting it, or by ".gitignoring" it?

I think I know how I can fix it (rake db:create or similar) but what I don't understand is, if in Capistrano v3 it knows it's a first time, why it would not use the schema directly rather than run all the migrations? I'm a noob, that seems reasonable, but on the other hand, running the migrations would achieve the same result, so... (But what about folks who don't what to use the migrations blindly in production; won't they be stuck?) Thanks.

Answer 1

db:migrate takes the migration files and executes them. so if a table doesn't exist, it will tell you that so. If your deploy is the first deploy to that machine, or that the DB configured is yet have been initialized you should do:

1. Create DB

   rake db:create

this is will create all tables

2 Run the Migrations

 `rake db:migrate`

Here obviously, you need to have migrations in place.

It is highly recommended not to load a schema (unless you have no choice) since its hard to work on the schema after (rollbacking, etc) but if you have no choice you can do rake db:schema:load

see this for more info

rake db:schema:load vs. migrations

How to update production database schema safely in rails 3.1.3?

Answer 2

Ultimately what I did was as lmars and Nick suggested. I ran something like this directly on the production machine:

RAILS_ENV=production bundle exec rake db:drop
RAILS_ENV=production bundle exec rake db:schema:create
RAILS_ENV=production bundle exec rake db:schema:load

This destroys the data in the datbase of course, but on first deploy, that's not an issue.

I would think there's an easier way, but... I don't know it.

Answer 3

Check your database.yml config, production part, if it is correct. Then ensure Postgresql server is running on the production server and the application (as a user) has access rights. I assume "deployer" is the user, so check this user has all the necessary rights.

Answer 4

From the error it looks like you are trying to rename the client_infos table to clients but the client_infos table does not exist, but do you not have an earlier migration which created the client_infos table?

If you don't have a migration which creates the client_infos table, then where did it come from? Did you create it manually? All changes to the database should have an accompanying migration.

If you do have a migration for the client_infos table, the schema_migrations database table (which is where Rails keeps a record of what migrations have run) may of somehow got out of sync. Given you are deploying for the first time, its probably worth dropping the whole database and starting again.

What I don't understand is why the migration is running at all? Why isn't the the database just being created from the schema on the first run

If written correctly, the migrations should have the same effect as loading the schema, they will just do it incrementally. You can of course manually load the schema if you wish, but Capistrano will not do this as it is quite a dangerous thing to run (you likely never want to recreate your production database)