I would sort of expect that to be the behaviour -- it's inside a transaction. Once it saves the record, it knows the id, which it updates the ActiveRecord object with. Then the transaction is rolled back, so that id is never in the database.
On Thu, Jan 19, 2012 at 13:30, Rex Chung <[email protected]> wrote: > Has anyone seen problems with deadlockretry gem ? > > The problem seems to be more specifically to Rails ActiveRecord. > > When I raised an error (to mimic a deadlock error) in after_create > within a transaction, the instance model is modified and thinks that > it is saved successfully and not a new record anymore. > > Here's the gist - https://gist.github.com/1637279 > > class User < ActiveRecord::Base > after_create :deadlock_on_first_try > > def deadlock_on_first_try > raise ActiveRecord::StatementInvalid.new("Lock wait timeout > exceeded") if @deadlocked.nil? > ensure > @deadlocked = true > end > end > > # In the console... >>@user = User.new >>@user.name = "foo" >>User.transaction do @user.save end > ActiveRecord::StatementInvalid: Lock wait timeout exceeded >>@user.new_record? > false >>@user.id > 1 >>User.find(1) > ActiveRecord::RecordNotFound: Couldn't find User with id=1 > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
