Hi all, I've seen examples on including "development data" in migrations. I do this myself, and it seems to be a great convenience for "trying out" an application. This saves all the trouble of entering the setup data that may be necessary to use the application. My question is about what to do when it comes time to run the migrations on the production database. How do we keep all this "development data" from infecting the production database. Is there some way to skip migrations (or have the migration do nothing) when run with RAILS_ENV set to "production?" There may also be cases where I may want some of the data to be loaded in the production database, which could include things like enumerations providing some defaults that can be expanded upon later by the users or administrators. I assume this could be accomplished by using conditionals embedded within the migrations, given that they are basically just Ruby code. However, I'm also guessing that there may be some "built-in" support for this that I've not yet found in my research on Rails and migrations.
on 2007-05-24 16:50
on 2007-09-25 23:02
There is no built-in environment-aware support in migrations. What we end up doing at RHG is having environment specific SQL files and using environment-aware data loader to load them. See the details here - http://revolutiononrails.blogspot.com/2007/02/data... Val