> I know why SQLite3 is broken. This code: > > Topic.transaction do |transaction| > transaction.rollback! > end > > results in the following database commands: > BEGIN; > ROLLBACK; > COMMIT; > > In other words, there is a COMMIT when no transaction is in flight. > MySQL and Postgres are coll with it, but SQLite3 blows up with > indignation. > > Recorded as a ticket: http://dev.rubyonrails.org/ticket/8030
We've discussed this a while back, perhaps on campfire... However I think the real fix is to no longer rely on yielding the connection, and instead create an exception subclass which causes the transaction to be rolled back, and then return from transaction rather than propagating. This will let us ensure we don't try to commit after rollback, and also let people roll back from deeper scopes without passing around the txn. Thoughts? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
