views:

215

answers:

2

So take the following test in Rspec:

require 'spec_helper'
describe Author do
  self.use_transactional_fixtures = false

  after(:each) do
    Author.destroy_all
  end

  it "should behave normal when using transactions" do
    my_author = nil
    begin
      Author.transaction do
        my_author = Author.new(:name => "My Name")
        my_author.new_record?.should be_true
        my_author.save!
        raise "some exception"
      end
    rescue
    end
    Author.count.should == 0
    my_author.new_record?.should be_true
  end
end

The last line:

my_author.new_record?.should be_true

gives:

'Author should behave normal when using transactions' FAILED
expected true, got false

at least when you roll back some record creation, I expect it to roll back completely, so resetting the new_record? and the id too. Am I missing something here? Is this intended? I'm using rails 2.3.5

A: 

Yes, this is intended. The transaction operation is a database-only block. It will not change anything about about your in-memory ruby objects.

Drew Blas
new_record? is a method that is supposed to reflect the database state.
dasil003
+2  A: 

Delph, this is a bug in rails. It should reset id and new_record, but it does not.

See the link below for more info

https://rails.lighthouseapp.com/projects/8994/tickets/1948-transaction-block-sets-model-id-to-non-existent-row

Pieter