I was also annoyed by the change to db:reset, which is why I then wrote rake db:rebuild. I mainly use it when I'm in the early stages of development and my migrations are going through some changes. I could rollback to and then migrate back up, but I just prefer the short syntax of db:rebuild.
rake db:test:clone clones your test database from your schema (same as rake db:reset - from schema) I prefer to have a test database up from the get go (which is why I have it in rake db:build) and when I remigrate. The reason I prefer migrations over the schema is that I usually have some data in my migrations, e.g. admin user, that I'd like to have setup. I'm sure I'm not the only one who has some data in the migrations. The rake db:create:test came about because I wanted to have rake db:build and have my test database setup(with the current schema). You can't do rake :build => ["rake db:create RAILS_ENV=test"], it will fail and rake db:create:all will create all databases defined in your yaml file - I didn't want that either. Those were my reasons why these came about and why I've been using them for a while now. Am I missing something or doing something here that shouldn't be done? Matt Aimonetti wrote: > I recently had a long discussion with David Heinemeier Hansson. I was > a bit annoyed at the fact that rake db:reset was changed to use the > schema file. > > Here is my explanation of how I use rake db:reset > > I've been using rake db:reset mainly in the testing environment. Since > I do TDD, I usually don't create a migration all at once. > I write a test, generate the migration needed for the test to pass, > add the code, migrate, test passes. I refactor, write another test, > modify the migration, db:reset, write more code, test passes. I also > use rake:db:reset to make sure migrations won't break. > > David made a good point saying that: > > You're just iterating over one migration, which > db:rollback + db:migrate would deal with. I can sympathize with that > one. I just don't see the need to run ALL migrations again. Especially > not on production systems that might have hundreds of migrations. > > I definitely get the point of verifying the current migration you're > working on. Perhaps something like db:regrate => [ db:rollback, > db:migrate ] would solve that case? > > ---- > > db:rollback has a nice STEP option that let's you migrate 'back' few > versions. > > rake db:build is a good idea, but David made clear that we should use > the schema.rb file to bring your db to the latest state. On top of > that I don't understand the need to clone your dev env to your test > development. > > rake db:create:test is the same as rake db:create RAILS_ENV=test or > rake db:create:all > > ---- > > I'll submit a patch for rake db:regrate if you have a suggestion for > a better name, please post here or on the track ticket. > > -Matt > > > On Nov 29, 6:27 pm, Robert Evans <[EMAIL PROTECTED]> -- 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 -~----------~----~----~----~------~----~------~--~---
