I really like Alexey idea of a ruby file for loading the seed data and run it with a rake task. Should that be something in rails or rather "best practices"? Or should we have something akin to create_table that's like create_data_for :users do... within something like ActiveRecord::SeedData? (with associated rake tasks)
Granted that my case may be one of few. With that said, what do you think about my proposed rake tasks, minus the db:test:clone? That way, we can build the test db with a rake task, and can rebuild from migrations as well? Or am I still off the mark? DHH 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. -- Posted via http://www.ruby-forum.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 -~----------~----~----~----~------~----~------~--~---
