I assume there’s now something I’m totally missing here.
I’m creating stuff in examples, just plain Foo.create, and the results
aren’t getting rolled back. I’m keep getting the following kind of
pattern in my logs
… log from example starts here …
SQL (0.0ms) BEGIN
SQL (0.0ms) BEGIN
ClassFoo Create (0.2ms) INSERT …
Group Load (0.4ms) SELECT …
Contains Create (0.2ms) INSERT …
… other stuff from example, no transaction stuff …
SQL (1.9ms) COMMIT
SQL (0.1ms) ROLLBACK
… log from example ends here …
all examples of the following form produce it
describe ClassFoo do
…
it “plim-ploms” do
foo = ClassFoo.create
…
end
…
end
I’m just wondering if this is caused by those nested transactions.
MySQL (which I happen to use) doesn’t support nested transactions and
is documented to just silently commit open transaction on new BEGIN.
Taken that I’d expect last ROLLBACK not to have any effect.
Where do those transactions come from? I’d guess outer transaction
to be from RSpec and inner from ActiveRecord (oh, I’m on Rails).
I’m creating stuff in examples, just plain Foo.create, and the results
aren’t getting rolled back. I’m keep getting the following kind of
pattern in my logs
You probably thought about this already, but did you check the setting
of config.use_transactional_fixtures in config.spec_helper.rb?
Yes, but only one spot (iirc) which is not anywhere near the model
whose test is failing here. I’ll verify tomorrow that the failing
test really doesn’t run the app code in question.
Verified, and it didn’t. Transactions I see on the log when running
the spec in question come from ActiveRecord (and RSpec if I have
use_transactional_fixtures = true).
Yes, but only one spot (iirc) which is not anywhere near the model
whose test is failing here. I’ll verify tomorrow that the failing
test really doesn’t run the app code in question.
Spec::Runner.configure do |config|
config.use_transactional_fixtures = false
…
tables_to_truncate =
ActiveRecord::Base.connection.tables - [“schema_migrations”]
config.before(:all) do
tables_to_truncate.each do |table_name|
ActiveRecord::Base.connection.execute(“TRUNCATE TABLE
#{table_name};”)
end
end
…
end
And if I run rake spec all specs pass. But if I run script/spec
spec/models/class_foo_spec.rb then
it “finds no ghost foos” do
ClassFoo.should have(:no).records
end
fails. That is the first example of describe ClassFoo. Looks like
script/spec runs examples (see pastie http://pastie.org/354521) in the
order they are defined and rake spec in reverse order. And that of
course makes ClassFoo.should have(:no).records fail when run after
examples that create ClassFoo instances (befause ive got transactions
off and the db state “bleeds” within one describe.
2009-01-07 16:11, Tero T.:
SQL (0.1ms) ROLLBACK
… log from example ends here …
If I turn use_transactional_fixtures off, the outer transaction is
gone.