It seems like it'd be pretty easy to do, though you might have to override the deploy:cold task.
However, I think the reason for the current behavior is that loading the schema nukes whatever data was there. Using migrations is a sane default, in that it preserves data. The only way I can think to improve it would be to detect when none of the tables exist, and run db:schema:load in that instance -- and migrate if any tables exist. On Thu, May 22, 2008 at 10:42 AM, ak <[EMAIL PROTECTED]> wrote: > > Is there any way to have "cap deploy:cold" run the schema.rb file > instead of trying to migrate the empty database? > > The schema.rb file is considered the 'authoritative' definition of the > db schema, so it makes sense to use this file to do initial database > setup instead of migrating from 0. In fact, in Rails 2 the schema.rb > file contains this statement: > > # Note that this schema.rb definition is the authoritative source for > your database schema. If you need > # to create the application database on another system, you should be > using db:schema:load, not running > # all the migrations from scratch. The latter is a flawed and > unsustainable approach (the more migrations > # you'll amass, the slower it'll run and the greater likelihood for > issues). > > The project I am working on has made me a firm believer that "the more > migrations you'll amass, . . . the greater likelihood for issues". > Old migrations are fragile if you make frequent model changes, and the > likelihood that a deploy:cold using migrations will work when > deploying to a new environment is slim to none. > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
