"...migrations are transient artifacts that only serve the purpose of moving everyone on a schema version A to schema version B."
David, Koz expressed almost exactly this same sentiment yesterday in another thread (http://groups.google.com/group/rubyonrails-core/browse_frm/ thread/d871469cb2a6589a?hl=en). You guys are consistent in the message. But there is an argument being expressed in these threads, plugins and trac tickets for using migrations for more than just one- time changes. I use migrations for building the databases FROM SCRATCH for both development and production. And I would like to do the same in test because it works so well for development and production. *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. 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). 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. On a related note, there seems to be a migration-versus-fixtures debate for seed data coming over the horizon. There is no reason you can't do a hybrid by loading fixtures within a migration. In fact, such an approach is described in Agile Web Development with Rails (page 271, section 16.4). It works well and capitalizes on two well- tested and understood Rails tools. 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. -Chris On Nov 30, 3:35 pm, DHH <[EMAIL PROTECTED]> wrote: > > > In that context, it doesn't make sense to use migrations for the test > > > database because the test database does not have permanent data of > > > importance. > > > I think, it does make sense to run migrations in the continuous > > integration loop (but not in the local build). Reason: you want to > > test them, but you don't want to slow down the local build. A fairly > > common practice is to use 001_initial_schema migration as the only > > migration on the project for as long as there is no valuable > > production data to preserve. > > I don't think I understand this. Why do you want or need to > continuously test the migrations? In my opinion, migrations are > transient artifacts that only serve the purpose of moving everyone on > a schema version A to schema version B. Once everyone has been moved, > the migrations are useless and could essentially be deleted. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
