> *Development: (Before going live and before production even exists) > Occasionally I will end up with a development DB that is full of cruft > and I want to reset. So I drop the development DB and rebuild. > *Production: After months of development, I'm ready to put an app into > production, so I contract with a hosting site and build it from > scratch.
Both of these scenarios are intended to be solved with db:schema:load. That task isn't working for you because you're putting seed data into migrations. In turn, you feel pain from db:schema:load because it doesn't include your seed data. I think the problem here is seed data in migrations, not migrations vs schema. > What both these scenarios have in common is that the ruby schema > dumper is inadequate (no DB-specific stuff supported) and the sql > schema dumper is also inadequate (no non-DDL available, such as seed > data loading). In my mind, this is a perfect case for SQL schema dumper. You have a db-specific schema that uses tricks not accessible by the Ruby dumper. If you split out the concern of seed data, I think a lot of your problems go away. > Migrations work beautifully to address these problems > in a very Rails-like way (no plugin required!) and using syntax I've > already invested in. I can add an Admin user, a Guest user and their > authorizations and be able to use the app after rake db:migrate. 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. > It is unfortunate that such a great tool (migrations) can't also be > used to build the test DB. As it is now, I occasionally find my > migrations fail due to subtle DB-side changes or model changes. The > only way to keep them fresh is to manually rebuild a database from > time to time. But it sure would be nice if they could be used in the > day-to-day of building the test DB. Again, this is a symptom of wanting to run migrations all the time and thus needing to make sure they'll work for all eternity. I think that's a waste of time and hard too. You might very well have old migrations that depend on classes and methods that are no longer around. I've seen some of the hoops that people jump through to keep legacy behavior intact for migrations and it sure ain't pretty. So in summary, what we need is a seed system as either a best practice, plugin, or core (doubtful, it doesn't feel like a Most People, Most of The Time concern) and stop trying to turn migrations (or even fixtures) into a seed system. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
