I have a rails app that I'm moving to another server and I figure I should use db:schema:load to create the mysql database because it's recommended. My problem is that I'm using capistrano to deploy and it seems to be defaulting to rake db:migrate instead. Is there a way to change this or is capistrano using db:migrate for a good reason?
Mysql – db:schema:load vs db:migrate with capistrano
capistranodatabaseMySQLrakeruby-on-rails
Related Solutions
Now, the accepted way to set the humanized names and custom error messages is to use locales.
# config/locales/en.yml
en:
activerecord:
attributes:
user:
email: "E-mail address"
errors:
models:
user:
attributes:
email:
blank: "is required"
Now the humanized name and the presence validation message for the "email" attribute have been changed.
Validation messages can be set for a specific model+attribute, model, attribute, or globally.
Well, not having to use capistrano is a blessing :-). I grew to dislike it, but in fairness, it has gotten a lot better, and the doc here https://github.com/capistrano/capistrano/wiki/ addresses most of your issues -- the section on RVM might suffice as an alternative to rbenv. Your configuration should pretty much work with an out-of-the-box capfile.
EDIT: yeah, you'll need to do the tagging yourself, but the key is to think of the methods you write in the capfile as just system commands (remembering you probably don't have your normal shell path and other environment). Follow the examples of other git commands and you'll be fine.
EDIT: Better answer (maybe :-)
- Go here: https://github.com/capistrano/capistrano/wiki/2.x-From-The-Beginning
gem install capistrano
(note, typically this doesn't belong in your Gemfile)- cd
capify .
Createsapp/Capfile
andapp/config/deploy.rb
- You're using the asset pipeline, so in Capfile uncomment
load 'deploy/assets'
- Now, look at the deploy.rb
- application name is a name like "my_application"
- repository is the URL to your source control repo, e.g.
myusername@github.com:yourrepo/yourproj.git
scm: git
(right? If not, same idea: URL above and this for SVN, or whatever)role :web "www.example.com"
and since your :db and :app are all on one box, those are the same- you're using Passenger, so uncomment the lines as directed.
- not sure but you might have to
require "bundler/capistrano"
at the top - you'll need a
set :deploy_to, <remote installation path>
maybe"/var/www"
- follow the other steps in the guide
- hypothetically after these and the steps I missed, check all of this in, and make sure your app is checked in (and pushed if git), and do the
cap deploy:setup
Hypothetically, setup will configure your server accordingly. Most likely error here is that your current machine needs permissions to ssh to the remote machine, and the remote machine needs access to the source control repository. Public keys are your friend.
After this, the workflow is:
- make changes
- test locally
- commit, and push to git
cap deploy migrations
(the migrations part is only necessary if you have done any)
Most organizations have some sort of staging or test servers. Look for "multistage" to get it so you can do cap test deploy
and cap staging deploy
etc.
To deploy a branch (and I think a tag) on git it's cap -S <branch/tagname> deploy
(make sure it's capital S, might be lowercase).
Once you get this going, there are probably things you'll want to do before or after the deploy -- for example sending email, regenerating a sitemap, backing up the database and so on. Use the before or after hooks to write your own tasks.
So the worst part of capistrano is that all the doc assumes you know what the hell it does. In a nutshell, it uses ssh (ruby's net-ssh) to execute commands on a remote server from whatever local workstation you deploy from. It looks at the head of your source tree (or tag or branch if specified), pulls that into a new location on your server, does anything else (migrations, asset precompilation) and gets the app ready; once it looks good, it changes a symbolic link (e.g. /var/www/current
to point to the new location and then (in the case of Passenger) calls touch app/tmp/restart.txt
to cause the server to restart.
Better?
Best Answer
Why to use db:schema:load
I find that my own migrations eventually do some shuffling of data (suppose I combine first_name and last_name columns into a full_name column, for instance). As soon as I do any of this, I start using ActiveRecord to sift through database records, and your models eventually make assumptions about certain columns. My "Person" table, for instance, was later given a "position" column by which people are sorted. Earlier migrations now fail to select data, because the "position" column doesn't exist yet.
How to change the default behavior in Capistrano
In conclusion, I believe
deploy:cold
should usedb:schema:load
instead ofdb:migrate
. I solved this problem by changing the middle step which Capistrano performs on a cold deploy. For Capistrano v2.5.9, the default task in the library code looks like this.I overrode the task in my
deploy.rb
as follows.