On Nov 17, 4:50 pm, Jeremy Evans <[email protected]> wrote: > On Nov 17, 11:49 am, Jeremy Evans <[email protected]> wrote: > > > On Nov 17, 9:33 am, John Firebaugh <[email protected]> wrote: > > > > How about the attached patch? > > > > 0001-Ensure-transactions-around-save-and-destroy-are-roll.patch > > > 11KViewDownload > > > Looks good. Committed with minor changes: > > >http://github.com/jeremyevans/sequel/commit/c89a4e47a22d7741745b625d2...... > > > Thanks for your help! > > > Jeremy > > One thing I just thought about is how the following code will react to > these changes: > > album = Album.frist > album.raise_on_save_failure = false > album.use_transactions = true > DB.transaction > if album.save # Assume before hook fails > dothis # not called > else > dothat # not called > end > end # this transaction rolled back > > Because of how Sequel is set up (transactions are automatically > reentrant, no implicit savepoints), that will abort the outer > transaction, changing how the above code will function. The crux of > the issue is that you don't know whether or not you are already inside > a transaction, and if you are already inside a transaction, raising > Rollback is the wrong thing to do. > > A special exception type that would abort the transaction inside save/ > destroy, but still caught by save/destroy so they can return normally, > is probably the best way I can currently think of to handle it, but > I'm open to ideas.
I committed a patch for this in my local branch (http://pastie.org/ 703635.txt), it should be pushed to github tomorrow after it goes through the full test suite. Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=.
