diff options
| author | Doug Barth <doug@pagerduty.com> | 2013-11-05 10:04:00 -0800 |
|---|---|---|
| committer | Doug Barth <doug@pagerduty.com> | 2013-11-05 11:47:08 -0800 |
| commit | 5d870c929157b7c7949c9356d4f88b97c8848ec3 (patch) | |
| tree | b9daf6484495a9c24fdd60fbe695068fb045d296 /activerecord/test/cases/validations/association_validation_test.rb | |
| parent | 44406d1e77061ce22effaae4698918c1f9f6271a (diff) | |
| download | rails-5d870c929157b7c7949c9356d4f88b97c8848ec3.tar.gz rails-5d870c929157b7c7949c9356d4f88b97c8848ec3.tar.bz2 rails-5d870c929157b7c7949c9356d4f88b97c8848ec3.zip | |
Don't swallow exceptions in transctional statements
The MySQL connection adapater swallows all StandardError exceptions,
which includes Mysql::Error and Mysql2::Error. The comment in the
exception clause claims errors thrown here indicate that transactions
aren't supported by the server but that isn't necessarily true. It's
possible the MySQL server has gone away and swallowing a failed commit
may let the application return a successful response when the data has
not been saved. Also, replication libraries like Galera require that the
application handle exceptions thrown at BEGIN/COMMIT.
I'm unable to determine what version of MySQL threw an exception for
transactional statements. I tried as far back as 3.23.49 with InnoDB
disabled but BEGIN & COMMIT statements do not throw an error. If there's
a real case for this logic to continue, we could instead push this
behavior into a configuration setting.
The exception swallowing has been there since the beginning:
db045dbbf60b53dbe013ef25554fd013baf88134
Diffstat (limited to 'activerecord/test/cases/validations/association_validation_test.rb')
0 files changed, 0 insertions, 0 deletions