[snip] > Again, I think this is a mistake and it was certainly not what > migrations were designed for. They lead to all the pains and problems > you're describing with migrations. > > I fully realize that people are misusing migrations in this way > because they were missing a seed system and just grabbed something > that had the same vague outline. But I think the problem then is to > consider how to best do seeding. Not to twist migrations into a seed > system.
I'm one of the people misusing migrations in this way, and a seed system could fulfill part of the problem, but not all of it. I often use migrations for creating data that needs to be present in every environment. For example, a new account in an accounting table. I want to add that to an existing production application without reloading all of the data. By including it in a migration, I'm sure that it will exist in the database of every developer, our integration environment, and finally production. It keeps me from having to track down data bugs. Of course, the fact that I also have to encode that data into my fixtures isn't very DRY. I'd love to have some way of specifying the data only once, I just don't have any brilliant ideas about how to do it. [snip] Mike Mangino http://www.elevatedrails.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
