diff options
author | Jon Leighton <j@jonathanleighton.com> | 2013-05-03 11:27:59 +0100 |
---|---|---|
committer | Jon Leighton <j@jonathanleighton.com> | 2013-05-03 11:36:02 +0100 |
commit | 66982772b7b019505870a65b38af076d509ffd53 (patch) | |
tree | cf0207f8019ea1212a3158dde2372f718eff6ed1 /activesupport/lib/active_support/testing/isolation.rb | |
parent | efaecadaf9cc2f3b55df04f3355dbc298a544a46 (diff) | |
download | rails-66982772b7b019505870a65b38af076d509ffd53.tar.gz rails-66982772b7b019505870a65b38af076d509ffd53.tar.bz2 rails-66982772b7b019505870a65b38af076d509ffd53.zip |
Fix broken mysql test
test_mysql_integer_not_null_defaults in test/cases/defaults_test.rb was
failing. This test relies on the connection being in strict mode. By
default a new connection is not in strict mode, but Active Record
automatically places it in strict mode.
ActiveSchemaTest overwrites the connection's #execute method in order to
prevent SQL statements from actually being executed. One of the
operations which is performed in ActiveSchema test is a #recreate_database.
Since 2088bf27981137a2c6c8b2f718f33b417b4045af, recreate_database on
mysql or mysql2 will trigger a reconnect.
Due to the implementation of the hacking of #execute in
ActiveSchemaTest, this reconnect would take place, but the connection
would *not* be placed in strict mode because #execute had been
overridden to prevent SQL queries hitting the database.
Therefore, after ActiveSchemaTest, the connection would no longer be in
strict mode, causing test_mysql_integer_not_null_defaults to fail.
I don't think that the way that ActiveSchemaTest is implemented is
particularly nice or clean, but I have taken steps to make its hacks
more isolated - it now create a separate connection object which is
thrown away after the test, and the hacks are applied on the singleton
class of this object.
Diffstat (limited to 'activesupport/lib/active_support/testing/isolation.rb')
0 files changed, 0 insertions, 0 deletions