diff options
| author | Yves Senn <yves.senn@gmail.com> | 2014-07-24 16:38:41 +0200 |
|---|---|---|
| committer | Yves Senn <yves.senn@gmail.com> | 2014-07-24 16:42:34 +0200 |
| commit | 091b246bb0111357edbb9703ea342a944b04deb6 (patch) | |
| tree | ce8348afd4c96f5299d32ccef81cd9041cede699 /tasks | |
| parent | a208fb764727e32a598450f6146df4545845cb45 (diff) | |
| download | rails-091b246bb0111357edbb9703ea342a944b04deb6.tar.gz rails-091b246bb0111357edbb9703ea342a944b04deb6.tar.bz2 rails-091b246bb0111357edbb9703ea342a944b04deb6.zip | |
fix, mysql `db:purge` respects `Rails.env`.
Previously this method always established a connection to the test database.
This resulted in buggy behavior when combined with other tasks like
`bin/rake db:schema:load`.
This was one of the reasons why #15394 (22e9a91189af2c4e6217a888e77f22a23d3247d1)
was reverted:
> I’ve replicated it on a new app by the following commands: 1) rails
generate model post:title, 2) rake db:migrate, 3) rake
db:schema:load, 4) rails runner ‘puts Post.first’. The last command
goes boom. Problem is that rake db:schema:load wipes the database,
and then doesn’t actually restore it. This is all on MySQL. There’s
no problem with SQLite.
-- DHH
https://github.com/rails/rails/commit/22e9a91189af2c4e6217a888e77f22a23d3247d1#commitcomment-6834245
Diffstat (limited to 'tasks')
0 files changed, 0 insertions, 0 deletions