The difficulty with the decorator approach is that, at least in the case of my "DataError", in the course of executing modelinstance.save(), nobody has called transaction.set_dirty(), so the commit_on_success decorator's wrapper doesn't call rollback.
If I caught the error inside of the wrapper, I could call rollback myself. But the wrapper has this nice handler that I'd like to use. So, if I call transaction.set_dirty() before the first save in my wrapped function, everything appears to work. For previous times through the loop, where there were no errors, commit_on_success's wrapper will have called commit. I'm assuming that the rollback will only roll back to the most recent commit, so I won't be loosing things from previous successful iterations of the loop that calls the wrapped function. So I don't need to become involved in savepoints. Does anyone spot a fallacy? Bill On Thu, Apr 15, 2010 at 11:27 AM, Bill Freeman <ke1g...@gmail.com> wrote: > I'm following you now. I was reading through the transaction.py code after > David's post, and had just come to the same conclusion. > > I have a function (called in a loop) that contains all my model get's and > saves, > so I tried the commit_on_success decorator. Sadly, the next database > interaction after the failing save, which is a get in the beginning of the > function on the next time through the loop, fails with: > > current transaction is aborted, commands ignored until end of > transaction block > > Perchance I also need to create a savepoint and do savepoint_rollback? > > Bill > > On Thu, Apr 15, 2010 at 11:03 AM, Thomas Guettler <h...@tbz-pariv.de> wrote: >> >> >> Bill Freeman wrote: >>> How does this apply when there is no request? I'm not following you. >> >> I forgot to say, that I would create a temporary script file which >> uses the decorator commit_on_success instead of using "manage.py shell". >> >> Thomas >> >> >> -- >> Thomas Guettler, http://www.thomas-guettler.de/ >> E-Mail: guettli (*) thomas-guettler + de >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
