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 < jonathan.lozin...@gmail.com> 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 <rr.ro...@gmail.com> > 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 rubyonrails-core+unsubscr...@googlegroups.com. > > To post to this group, send email to rubyonrails-core@googlegroups.com. > > 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 rubyonrails-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > 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 rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
