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.

Does not seem like a stock set of capistrano recipes for deployment, so its hard to tell what causes this. — Tanel Suurhans, Feb 09 '14 at 03:04
For example, why does the first run NOT do something like this: RAILS_ENV=production rake db:create db:schema:load — codenoob, Feb 09 '14 at 03:15
gmaliar - Great suggestion, but cap deploy:cold is deprecated in Capistrano v3, which I should have mentioned I'm using. — codenoob, Feb 09 '14 at 20:20

codenoob · Answer 1 · 2014-02-12T00:29:10.023

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.

score 0 · Answer 2 · answered Feb 09 '14 at 14:29

0

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.

answered Feb 09 '14 at 14:29

Nikos

515
1
4
16

Nikos, thanks for the suggestion. I can connect using psql -h (ip address) -U (correct username) and -d (database name) from another machine. The database user is NOT the same user that is the deployer, but I have the db setup as m5, and the database.yml part (the only part is prod) looks OK. – codenoob Feb 09 '14 at 20:42

score 0 · Accepted Answer · edited May 23 '17 at 10:29

0

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:

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?

edited May 23 '17 at 10:29

Community

1
1

answered Feb 09 '14 at 14:41

Nick Ginanto

31,090
47
134
244

2

Thanks Nick. Definitely useful info, and I think I may do just what you're suggesting, but in this instance, my question is really about why Capistrano (v3.x) is doing what it's doing. I want to be able to figure it out so that if I deploy this way again, it will work.(I one up'ed your response.) – codenoob Feb 09 '14 at 20:18
I believe I am not able to run rake db:create to deploy successfully just because before deploy i don't have any project files on remote server, except for database.yml created manually, so rake just wont run without rakefile. Am I expected to do everithing to run rake before first deploy? – antiplayer Mar 31 '16 at 16:32

score 0 · Answer 4 · answered Feb 09 '14 at 14:45

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)

Imars, thanks for looking at this. You're right, the error is about the table (I think in my question I noted the table it's complaining about doesn't exist). My question is really about why the migrations are running at all in this case. I one-uped your answer, I don't think it answers the question (though it does give me some more ideas about how to fix it). Thanks. — codenoob, Feb 09 '14 at 20:16

Why Does First Deploy with Capistrano Run db:migrate?

4 Answers4