Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

Rake tasks db:create and db:drop are not consistent in behaviour

#5313

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.

Reported by Russell Quinn · August 6th, 2010 @ 08:56 AM

State: open
Milestone: none
Assigned to: Mikel Lindsaar Mikel Lindsaar
Importance: Low

Activity

  1. Russell Quinn
  2. Kane
  3. Marjan Krekoten'
    Marjan Krekoten'
    • 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.

    September 20th, 2010 @ 01:48 PM

  4. Kane
    Kane

    i cant see the point why it should create test db.

    September 20th, 2010 @ 07:35 PM

  5. Russell Quinn
    Russell Quinn

    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.

    September 27th, 2010 @ 09:55 AM

  6. Jeff Kreeftmeijer
    Jeff Kreeftmeijer
    • 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. :)

    October 6th, 2010 @ 05:10 PM

  7. Jeff Kreeftmeijer
    Jeff Kreeftmeijer
    • State changed from new to open
    • Tag changed from activerecord rails3, rake tasks, patch to rake tasks, activerecord, patch

    October 9th, 2010 @ 08:28 AM

  8. Santiago Pastorino
    Santiago Pastorino
    • Assigned user changed from Santiago Pastorino to Mikel Lindsaar

    October 9th, 2010 @ 05:00 PM

  9. viktor tron (strawberry)
    viktor tron (strawberry)

    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...

    January 12th, 2011 @ 02:55 PM

  10. ronen barzel
    ronen barzel

    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
    

    March 24th, 2011 @ 05:44 PM