>>"You run your migrations against your development database, it's hardly as >>bad as you're implying :)."
True, but... In development, you run the new migrations -you don't typically tear down the DB and run all of them from the start. Consequently, older migrations become stale and broken (due to DB upgrades, model changes, etc.) -and you don't learn about that until it's too late. I maintain that the current functionality leaves no reasonable means of keeping migrations up-to-date and tested in their entirety. It doesn't sound like you use your migrations in their entirety to build a DB so perhaps you have not been bitten by this problem. I see this issue is distilling into three separate arguments for migration-based test DB setup: 1. migrations (in their entirety) need testing too 2. migrations are the most capable means of building a database (including test). 3. Rails is sending an inconsistent message: migrations for development and production, but schema dumper for test. What's the argument for the schema dumper? This thread is probably reaching the end of it's useful like, but I would like to close with a request: please consider endorsing (test, +1) ticket 8389 or something similar. Chris On Nov 29, 3:53 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > > Josh's rake task looks like it provides a nice ability to load data > > via Rake. But there is an inconsistent message being sent by Rails: > > > Use Migrations. Use Migrations. Use Migrations. > > > Except for testing, where we'll use a limited, one-off method (schema > > dumper) ensuring that you'll never know if your migrations are broken > > until it's too late. > > > > Is there a good reason for the avoidance of migrations for building > > the test DB, or is the use of schema dumper just a vestige of days > > gone by? I continue to be surprised by the lack of comments from the > > core team on this thread (Koz's early comment being the only one) and > > the lack of feedback on ticket 8389. > > Migrations are designed for cases where the data in your db matters, > with cases like a test database you might as well just drop and > recreate every table. > > But more than that, *most* of the migrations in my current > application (200ish out of 300ish) are for maintaining *data*, they > don't make schema changes at all. Things like fixing up data after a > bug messed it up, changing the prices of various plans, altering > lookup data Etc. My test database doesn't need to know about them. > Schema.rb works fine, I'm not sure what additional benefits you're > looking for. > > > > > For those of you that have bought into migrations like I have, add > > your thoughts (or improvements) to the patch on ticket 8389. > > > -Chris > > > On Nov 28, 5:22 pm, "Josh Knowles" <[EMAIL PROTECTED]> wrote: > > > On 11/13/07, Stephen Touset <[EMAIL PROTECTED]> wrote: > > > > > 1 ) What, then, is the preferred mechanism for "seed" data in the > > > > database? Currently, many people use migrations to insert bootstrap > > > > data. If schema.rb will be used for tasks like db:reset, none of this > > > > data will be loaded. > > > > I've written a simple rake task that loads any .rb files found within > > > the RAILS_ROOT/db/fixtures/RAILS_ENV directory. I've bundled it up as > > > a plugin if anyone else wants to try it > > > out:http://code.google.com/p/db-populate/. README, examples, etc. to come > > > soon. > > > > -- > > > Josh Knowles > > > phone: 509-979-1593 > > > email: [EMAIL PROTECTED] > > > > web: http://joshknowles.com > > -- > Cheers > > Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
