This looks like pretty much what I think should be available, only difference being the ability to specify what table to record the running to keep db:migrate free from non db concerns
Sent from my iPad On 27 Feb 2013, at 14:40, Allen Madsen <[email protected]> wrote: Here's the task I alluded to if anyone is interested: https://gist.github.com/blatyo/5047690 Allen Madsen http://www.allenmadsen.com On Thu, Feb 21, 2013 at 3:26 PM, Allen Madsen <[email protected]>wrote: > 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. -- 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.
