Wes Gamble
2006-Aug-09 00:00 UTC
[Rails] Different DB connections for migrations vs. running app.
All, I''ve run into a situation where I want the owner of my DB tables to be different than the user that accesses them during application runtime. I believe that I can just set up another DB connection profile (with a name other than "production") in database.yml and then pass that as RAILS_ENV to db:migrate instead of "production". Anyone see any problems with this? Yay - deployment issues. Wes -- Posted via http://www.ruby-forum.com/.
Wes Gamble
2006-Aug-09 00:01 UTC
[Rails] Re: Different DB connections for migrations vs. running app.
This seems to work. I did the following: Set up a new DB profile named prod_migrate that was only different than the existing production profile because of username/password. Copied the config/environments/production.rb file to config/environments/prod_migrate.rb and I was able to migrate into production using: rake db:migrate RAILS_ENV=prod_migrate I''m under the impression that the config/environments/xxx.rb file is necessary in case you''ve made sweeping configuration changes to the way that database tables and stuff are handled. Otherwise, it''s a bit of a pain. Wes -- Posted via http://www.ruby-forum.com/.
Maybe Matching Threads
- Capistrano only runs migration against production env?
- Verifying some understanding about manipulating DB data in before/after callbacks in RSpec
- ADVICE: Generating unique identifiers for later DB insertion
- rake migrate the first time - uses more than schema_info?
- rake migrate VERSION=0 doesn''t appear to execute