At Gazelle, we essentially copy the migration rake tasks and call them iterations. So, as you'd imagine:
rake iteration:migrate # like rake db:migrate We use it for data only changes. Allen Madsen http://www.allenmadsen.com On Thu, Feb 21, 2013 at 3:17 PM, Duncan Beevers <[email protected]>wrote: > One small thing I'd like to point out is that running migrations serially > is not the same as recreating the database from a schema dump. For example, > the Rails migration `timestamp` directive has flip-flopped in its behavior > (`created_at` was originally nullable, then not nullable, then nullable > again) so the effect of running a migration is a combination of the > migration's own code plus the underlying gems and application code in > effect at the time it runs. > > I like the idea of a sister directory to migrations to synchronize deploys > with the one-time tasks that accompany them. > > > On Thu, Feb 21, 2013 at 2:08 PM, Jonathan Lozinski < > [email protected]> wrote: > >> I agree. >> >> Whilst there might be a number of different things people do, rails >> providing some guidance, or reusable hooks to support the following would >> be helpful: >> >> 1. Seeding stuff after you have a live product >> 2. Running one-time tasks on a deploy without changing your automated >> release processes. >> >> Both lend themselves to having a open framework which migrations is >> 'built' on, which lets you use a gem or whatever to provide another >> 'tracked' table such as a seeds table or a 'deployment_tasks' table which >> uses the same basic techniques as the migration system, that is: >> >> 1. it will have a rails generator to build a skeleton class to perform >> the 'task' which is named with a timestamp etc like migrations >> 2. a rake task to run the task which will execute any 'unrun' jobs in the >> folder >> >> This would allow Rails' migrations to be built on top of this (and thus >> support rollback or whatever), but allow plugins or to build a system for >> more app specific tasks which don't however have to reinvent the robust >> framework that migrations currently has. >> >> >> On 18 Feb 2013, at 13:44, Rodrigo Rosenfeld Rosas <[email protected]> >> wrote: >> >> > Em 18-02-2013 08:05, mrloz escreveu: >> >> ... >> >> Additionally, rails doesn't (to my knowledge) provide a way to run >> db:seed after you have a live system which doesn't try and push prior seeds >> in too. What is the recommended way to add seeded values to new tables in >> a live system? >> > >> > I believe supporting a "seeds" table in addition to the migrations >> table would be a great idea. The same way we currently have migrations >> under db/migrations/ it would be great if we could have our seeds under >> db/seeds/. Then "rake db:migrate" would also run "db:seed" or whatever >> other task name you might prefer. When running rake db:reset the seed >> migration would be run after restoring the DB infra-structure. >> > >> > That sounds like a good tool to add to AR migrations. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "Ruby on Rails: Core" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > To post to this group, send email to [email protected]. >> > Visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
