Stephen, Your questions are a mirror of mine. I am surprised that the emphasis placed on migrations for building the development and production databases does not extend to the test database.
There is a rake task proposed on ticket 8389 (http:// dev.rubyonrails.org/ticket/8389) that addresses this problem by offering a third option to the config.active_record.schema_format setting. With the setting set to :migration, the test database is built with migrations. I have used this hack and it works tolerably. But I would really like to see it in edge to ensure that tools suppliers know it is an option. Also, right now it sets the test database to the same schema version as development whereas I think it should go to the latest version. It's great feeling knowing that my migrations are being exercised every time I run tests. I have been burned in the past with early migrations no longer being valid (due to DB upgrade) and not catching that problem until it was time to go into production. With this hack, I no longer worry about that potential problem. I also have moved to loading "seed" data with migrations. I really just load three records (a system admin user, a public group and some global permissions for them). But I expect to put some more seed data in this way -including Globalize languages and such. Lastly, I too use non-default DB options and that is, of course, no longer a problem. I would recommend that you look at ticket 8389 and I would ask Michael to look at it as well -it needs some "official" support (or a statement to the contrary). Regards, Chris On Nov 13, 11:17 pm, Stephen Touset <[EMAIL PROTECTED]> wrote: > Reading the Rails commit logs, I see that db/schema.rb's purpose has > been clarified. It's intended to be the authoritative location for > your database schema, and rake tasks like db:reset use it to rebuild > the schema rather than running migrations. > > This raises several questions for me. > > 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. > > 2 ) What about those of us who specify additional options like charset > or table types? This information, last time I checked, doesn't seem to > be saved in the schema.rb. > > 3 ) Should there be yet another database-related Rake task for > development? Many of us create migrations, then modify them until > we're ready to commit. A simple "rake db:reset" used to re-run the > migrations from scratch, but the new semantics mean that migration > changes are never reflected. > > Thanks in advance. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
