This project is archived and is in readonly mode.
Rake tasks db:create and db:drop are not consistent in behaviour
Reported by Russell Quinn | August 6th, 2010 @ 08:56 AM
db:drop drops the database for the current RAILS_ENV or development if not defined.
db:create creates the database for the current RAILS_ENV, but if this is set to development then it also creates the test database if this is configured.
This behaviour is hidden (the Rake task description doesn't mention it) and it makes doing a rake db:drop followed by a rake db:create complain about the test database already existing.
For example, the following happens if RAILS_ENV=development or there is no RAILS_ENV defined (hence defaulting to development):
$ rake db:drop
$ rake db:create
database_test already exists
Maybe rake db:drop should also drop the test database? But this also leads to sneaky functionality. My vote is that the two tasks simply do exactly what they state. rake db:create:all and rake db:drop:all can typically be used to create and drop development and test databases as the commands only operate on local databases and production is usually remote.
Patch attached to update the rake task and only mention of this behaviour (in a guide.)
Russell.
Comments and changes to this ticket
-
Marjan Krekoten' September 20th, 2010 @ 01:48 PM
- Assigned user set to Santiago Pastorino
I think it's nice to have test db created along with development. So I attached another patch which drops also test db while dropping development.
-
Russell Quinn September 27th, 2010 @ 09:55 AM
Why not just stick to the currently defined RAILS_ENV like everything else? I really don't think it makes sense to create test just because it's kind of convenient.
But, anyway, whichever way, create and drop need to do the same thing.
-
Jeff Kreeftmeijer October 6th, 2010 @ 05:10 PM
- Importance changed from to Low
I agree
db:create
anddb:drop
should do the same thing and I like Russell's patch better. As you said, also dropping the test database seems sneaky.It could use some tests, though. :)
-
Jeff Kreeftmeijer October 9th, 2010 @ 08:28 AM
- State changed from new to open
- Tag changed from activerecord rails3, rake tasks, patch to rake tasks, activerecord, patch
-
Santiago Pastorino October 9th, 2010 @ 05:00 PM
- Assigned user changed from Santiago Pastorino to Mikel Lindsaar
-
viktor tron (strawberry) January 12th, 2011 @ 02:55 PM
is there any update on if and when this change is pushed?
btw this ticket supercedes
https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets... -
ronen barzel March 24th, 2011 @ 05:44 PM
one additional motivation for consistent
db:drop
anddb:create
behavior: the taskdb:migrate:reset
calls both so currently yields a warning with every use after the first time. (i was looking for/going to create a ticket ondb:migrate:reset
but found this one.)$ rake db:migrate:reset > /dev/null $ rake db:migrate:reset > /dev/null db/test.sqlite3 already exists $ rake db:migrate:reset > /dev/null db/test.sqlite3 already exists
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>