#5313 Rake tasks db:create and db:drop are not consistent in behaviour - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#5313 open

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

You flagged this item as spam.
Russell Quinn August 6th, 2010 @ 08:59 AM
Patch attached.
- make_databases_rake_consistent.diff 2.1 KB
You flagged this item as spam.
Kane September 4th, 2010 @ 04:40 PM
i encountered this too, see #5382
You flagged this item as spam.
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.
- db_drop.patch 1 KB
You flagged this item as spam.
Kane September 20th, 2010 @ 07:35 PM
i cant see the point why it should create test db.
You flagged this item as spam.
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 and db: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”
You flagged this item as spam.
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...
You flagged this item as spam.
ronen barzel March 24th, 2011 @ 05:44 PM
one additional motivation for consistent db:drop and db:create behavior: the task db: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 on db: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
```