Update: I found a better way, see below

I use Capistrano to not only manage deployment tasks, but also to do lots of data management and monitoring tasks. By default Capistrano will try to deploy your code to whatever server you have set to the :db role, and will try to run the migrations there too. I don’t want to hassle with getting our full rails environment working on the db server so this was always a hassle.

A temporary solution was to just set the :db role to the same server as the :app role and the migrations would get run on the app server and all would be well. Later though if I had tasks that needed to actually work on the db server I’d have to manually change the :db role value. Very annoying.

To avoid this you have to do two things. First, on your :db role, add the :no_release option like so:

role :db,  "db.server.com", :primary => true, :no_release => true

This will ensure you don’t have your codes updated to the db server. Next you need to overwrite the default migrate task to not use the :db role. To do this just get the task code from your deploy.rb file. On my system this was in:

/Library/Ruby/Gems/1.8/gems/capistrano-2.4.3/lib/capistrano/recipes/deploy.rb

(I admit this is annoying because when you upgrade capistrano you may have to repeat this but I wasn’t able to figure another way.) Grab the migrate task and simply change the role it uses. It should end up looking like this:

 task :migrate, :roles => :app, :only => { :primary => true } do
    rake = fetch(:rake, "rake")
    rails_env = fetch(:rails_env, "production")
    migrate_env = fetch(:migrate_env, "")
    migrate_target = fetch(:migrate_target, :latest)

    directory = case migrate_target.to_sym
      when :current then current_path
      when :latest  then current_release
      else raise ArgumentError, "unknown migration target #{migrate_target.inspect}"
      end

    run "cd #{directory}; #{rake} RAILS_ENV=#{rails_env} #{migrate_env} db:migrate"
  end

Note that the role was changed to :app (from :db). And you’re done!

But wait! There is a better way!

Jamis Buck over in #capistrano eventually replied to a question I had there and explained that there is a much simpler solution:

[10:34am] jamisbuck: flippyhead: just set one of your app servers to :db, :primary => true
[10:35am] filmprog: so you've go and added new tasks to deploy:migrate ?
[10:35am] jamisbuck: and then put your db server in the :db role, with :no_release => false
[10:35am] jamisbuck: and without :primary => true
[10:35am] jamisbuck: then you'll have your db role
[10:35am] jamisbuck: but your migrations will run on the app server in question
[10:35am] flippyhead: I can refer to role :db twice?
[10:36am] jamisbuck: flippyhead: totally. there's no reason not to
[10:36am] flippyhead: ah, no kiddin!
[10:36am] jamisbuck: the migrations only run on :db where :primary => true
[10:36am] jamisbuck: any other :db server is ignored
[10:36am] jamisbuck: (by the migration task)

See, as it turns out you can “overload” roles. So instead of all that I just use this now:

role :db,  "server.com", :primary => true
role :db,  "db.server.com", :no_release => true

And everything works!

Just remember on those db only tasks to include :only => {:primary => false} to refer to the actual db role not the app db role.

I’m fed up with doing a bunch of complex model aggregation in my controllers. They are too bloated. Here’s a set of links I’m trying to make sense of as I decide what to do:

Seems like if you can avoid building an extra Presenter model and keep everything in your Rails models you’re better off, though the situation if complex enough, may dictate breaking such stuff out.

Handy in either scenario is Jay Fields validatable plugin for giving you better control over validations on collections of model objects.

The mass assignment stuff that was in edge but has been removed (dammit) may well have been perfect for my needs. As long as my form builders can produce posted parameters as nested hashes that match the model hierarchy I wouldn’t have to do anything by ParentModel.create(params[:parent_model]) and everything is taken care of for me.

Waggle Labs » Development

Disable deploying to your database server in Capistrano

But wait! There is a better way!

Complex forms, mass assignment, and the “presenter”