In this case you might want to create a migration Rails environment pointing
to the production database but with the migration user. Then, ask Capistrano
to execute db:migrate with migration environment.
With this configuration you don't need odd workarounds to switch users in
the same production
Great idea, everyone. Sounds a lot more straightforward - I'll go
with the alternative migration user.
On Mar 12, 4:41 am, Simone Carletti wep...@gmail.com wrote:
In this case you might want to create a migration Rails environment pointing
to the production database but with the migration
I usually grant all privileges to the database user except the ability to
GRANT or remove other permissions.
User access is restricted by IP to prevent unauthorized access from an
external client.
Capistrano itself doesn't provide any special task for changing privileges
but you can extend the
Thank for the quick response. You have a good point about the IP
restrictions and it's a good idea to use the all privileges without
the GRANT or removing of other permissions. I was starting to think
along those lines of extending the base deploy strategy, but I hadn't
read anywhere of people
One option is to set up another environment (development, test,
production, migration) with a separate entry in database.yml, and a db
user with increased privileges vs the production user. The capistrano
migrate task takes a parameter specifying the Rails environment.
I agree that you should
I'm with Sarah,
Make a migration user that is the production database, with a more able
user defined, use this account to run the migrations, which will still
affect the production database.
= Lee
2009/3/11 Sarah Mei sarah...@gmail.com
One option is to set up another environment
