Fixes the following issue:
1) Failure:
ActiveRecord::MySQLPurgeTest#test_establishes_connection_to_test_database [test/cases/tasks/mysql_rake_test.rb:200]:
not all expectations were satisfied
unsatisfied expectations:
- expected exactly once, not yet invoked: ActiveRecord::Base.establish_connection(:test)
satisfied expectations:
- allowed any number of times, invoked once: #<Mock:0x2349430>.recreate_database(any_parameters)
- allowed any number of times, invoked once: ActiveRecord::Base.establish_connection(any_parameters)
- allowed any number of times, invoked once: ActiveRecord::Base.connection(any_parameters)
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
22e9a91189 (commitcomment-6834245)
Closes#16261.
[Matthew Draper, Yves Senn]
Using `DEFAULT NULL` results in the same behavior as `DROP DEFAULT`.
However, PostgreSQL will cast the default to the columns type,
which leaves us with a default like "default NULL::character varying".
/cc @matthewd
Since the rubysl-yaml gem doesn't ship with Psych by default because of
its dependency on libyaml, on Rubinius, the default engine is Syck.
However, if we want to be able to run the application safely on
different rubies, we need to make people using Rubinius rely on Psych.
See http://git.io/uuLVag for further information.
The fixtures are still in play, adding a new column without a default and `null: true`
is not possible. This reverts back to leaking global state, as our `schema.rb` adds
the `null: false` constraint on this field.
A future solution would be to make the `migration_test.rb` run independent of fixture tables.
This way we can simply drop the state after test execution, without worrying about side effects.
/cc @zuhao
We are planning to remove mocha from our test suite because of
performance problems. To make this possible we should stop require mocha
on ActionSupport::TestCase.
This should not affect applications since users still need to add mocha
to Gemfile and this already load mocha.
Added FIXME notes to place that still need mocha removal
