ActiveSupport::TestCase fails to roll back?

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

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

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

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,

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.

>
> 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.