ActiveSupport::TestCase fails to roll back?

rubyonrails-talk
1

A simple test case that ran properly under 2.3 blows up in 3.0RC2 with the error:

Exception raised: <#<ActiveRecord::StatementInvalid: Mysql::Error: SAVEPOINT active_record_1 does not exist: ROLLBACK TO SAVEPOINT active_record_1>>.

People have reporte this error where there are concurrent processes, but mine is single process. Can someone teach me how to find out if this has been reported as a bug, and if not, what additional info / test case I can provide?

Thanks.

- ff

Additional info:

One possibly interesting thing: I can explicitly turn OFF transactional fixtures in test_helper.rb with:    self.use_transactional_fixtures = false ... at which point the rollback error goes away, but my tests fail because my tests expect the database to be empty, but it's not. (I thought that was the expected behavior of setting transactional fixtures to true, not false -- no matter).

My code (>>> marks the line that got the error):

  def test_basic_page_cache     assert_nothing_raised {@cache = PageCacheStore.find_or_create_page_cache(:web_page_cache)}

assert_nothing_raised {@cache.write("today", "Monday")}

    assert(@cache.read("today") == "Monday")     assert_nil(@cache.read("city"))     assert_nil(@cache.fetch("city"))

    assert_nothing_raised do       @cache.fetch("city") do         "Ducksberg"       end     end   end

The test log:

  SQL (0.2ms) BEGIN   SQL (0.6ms) SHOW TABLES   SQL (63.7ms) CREATE TABLE `web_page_caches` (`id` int(11) DEFAULT NULL auto_increment PRIMARY KEY, `key` varchar(255), `value` varchar(255), `expires_at` datetime) ENGINE=InnoDB   SQL (0.4ms) SHOW KEYS FROM `web_page_caches`   SQL (163.1ms) CREATE UNIQUE INDEX `index_on_key` ON `web_page_caches` (`key`)   SQL (0.4ms) SHOW TABLES   WebPageCache Load (0.2ms) SELECT `web_page_caches`.* FROM `web_page_caches` WHERE (`web_page_caches`.`key` = 'today') LIMIT 1   SQL (0.2ms) SAVEPOINT active_record_1   SQL (0.8ms) describe `web_page_caches`   SQL (0.5ms) INSERT INTO `web_page_caches` (`expires_at`, `key`, `value`) VALUES (NULL, 'today', 'Monday')   SQL (0.2ms) RELEASE SAVEPOINT active_record_1 Mysql::Error: SAVEPOINT active_record_1 does not exist: RELEASE SAVEPOINT active_record_1   SQL (0.1ms) ROLLBACK TO SAVEPOINT active_record_1 Mysql::Error: SAVEPOINT active_record_1 does not exist: ROLLBACK TO SAVEPOINT active_record_1   SQL (0.1ms) ROLLBACK

My config:

bash$ rake about About your application's environment Ruby version 1.9.2 (x86_64-darwin10.4.0) RubyGems version 1.3.7 Rack version 1.2 Rails version 3.0.0.rc Active Record version 3.0.0.rc Action Pack version 3.0.0.rc Active Resource version 3.0.0.rc Action Mailer version 3.0.0.rc Active Support version 3.0.0.rc Environment development

2

Update: Does ROLLBACK undo the creation of new tables?

I ask because find_or_create_page_cache(:name) has the effect of creating an AR table named "name" if it doesn't already exist. This appears to confuse the rollback mechanism under certain circumstances in Rails 3.0RC2, but I never had this problem in Rails 2.8.

- ff

3

Update: Does ROLLBACK undo the creation of new tables?

I ask because find_or_create_page_cache(:name) has the effect of creating an AR table named "name" if it doesn't already exist. This appears to confuse the rollback mechanism under certain circumstances in Rails 3.0RC2, but I never had this problem in Rails 2.8.

Assuming you're using mysql, this won't work - mysql doesn't support rolling back statements that change the schema (adding tables, columns etc...), executing any such statement implicitly commits the current transaction

Fred

4

Frederick Cheung wrote:

Update: Does ROLLBACK undo the creation of new tables?

I ask because find_or_create_page_cache(:name) has the effect of creating an AR table named "name" if it doesn't already exist. �This appears to confuse the rollback mechanism under certain circumstances in Rails 3.0RC2, but I never had this problem in Rails 2.8.

Assuming you're using mysql, this won't work - mysql doesn't support rolling back statements that change the schema (adding tables, columns etc...), executing any such statement implicitly commits the current transaction

Yet another piece of MySQL suckage. Assuming you're using MySQL, drop it in favor of Postgres...

Fred

Best,

5

Yet another piece of MySQL suckage. Assuming you're using MySQL, drop it in favor of Postgres...

Fred

Best, -- Marnen Laibow-Koser

MySQL 6 will introduce two new database engines which should replace innodb called Maria and Falcon which house this feature, along with recoverability features.

6

> > Yet another piece of MySQL suckage. Assuming you're using MySQL, drop > it in favor of Postgres... > >> Fred > > Best, > -- > Marnen Laibow-Koser

MySQL 6 will introduce two new database engines which should replace innodb called Maria and Falcon which house this feature, along with recoverability features.