On Sun, May 25, 2008 at 9:17 AM, ak <[EMAIL PROTECTED]> wrote: > > My understanding is that running deploy:cold is typically a one-time > setup operation, so there would be no data to nuke.
This is true. > Perhaps I'm missing something obvious, is it common practice to add > data to your application via migrations (something that would be > skipped by simply running the schema.rb file)? Maybe there are other > reasons to prefer migration from zero to loading the schema.rb file > directly during the initial setup of your app? Not really. Only one: If, for some reason, there is data there -- you ran deploy:cold accidentally, or you somehow got pointed at a different (critical) database, or whatever -- db:schema:load will happily blow it all away, while db:migrate will at least complain, and might even do the right thing. So my guess is, it's done this way as a bit of a safety net. I think db:schema:load should fail, instead of nuking what's there, if you run it on an existing database. There should be a separate rake task to run if there is data there which you actually want to nuke -- something like db:schema:drop_tables, or just db:nuke. But this would have to be patched in Rails first -- it's not Capistrano's domain. I will look into patching the deploy:cold behavior for my own project, > I guess my situation is somewhat abnormal. > Probably not. I actually often do some of these steps manually, rather than trust deploy:cold, but I won't be able to keep that up forever. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
