I've been thinking about this for a while, there's plenty of people who say data manipulation doesn't belong in migrations, though I haven't heard a lot of evidence as to why. This topic popped up again on "Chad Fowler's 20 Rails Development No-No's", #15: http://www.chadfowler.com/2009/4/1/20-rails-development-no-no-s , where a commenter says " If it’s created in a migration, it’s lost when you clone_structure_to_test, so it’s not available for your tests"
I think the primary reason developers do this is because there isn't a good alternative. If I want to roll out a new look-up table to a server, a migration is already in the right place at the right time when it's creating the table. Why make more work for myself and maintain it manually? My proposed solution is to formally provide a way in Rails to handle table seed data: - create a db/seed_data/ or db/table_init/ folder. I kinda like the latter. - on table create or after clone_structure, run the appropriate ruby scripts in db/table_init/ Advantages over seed data in migrations: - can be easily maintained and re-run at any time - stored in a central place instead of spread across many migrations - tests can use this to populate look-up tables after cloning dev structure Questions: - Are there any other reasons migrations are bad for seed data? Feedback is appreciated, I'm more than willing to code up the solution. Steven Soroka --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
