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-loaders-in-migrations.html
Val
On May 24, 10:17 am, Robert Walker
<rwalker...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> 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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---