On 01/18/2014 01:19 PM, Anssi Kääriäinen wrote: > On Saturday, January 18, 2014 9:02:41 PM UTC+2, Aymeric Augustin wrote: > > On 18 janv. 2014, at 19:50, Carl Meyer <ca...@oddbird.net > <javascript:>> wrote: > > > Those interested in this feature may find django-transaction-hooks > [1] useful. It is my attempt to implement the commonly-useful case > (run some code after the current transaction successfully commits, > providing the code wasn't registered during a savepoint which was > later rolled back.) I think the API provided by > django-transaction-hooks is actually better for that use case than > transaction signals are, since it does the work of handling some > situations correctly (savepoints, closed connections), which in the > case of signals are left up to the signal receiver to handle (or > more likely, not bother to handle.) > > > > Testing and feedback welcome. If this becomes widely used and > seems to fill a need, I think there is a chance it could become part > of Django core. (See #21803.) > > I think this is the right approach. I would use that package. I > support adding it to Django. > > > If documentation warns clearly that there is no guarantee whatsoever > that the hook is always ran after commit +1 for addition in Django. The > most obvious case of abuse for this sort of hook is doing something > business critical in the post-commit hook. It must be clear that this is > not a substitute for two phase commit or other ways of avoiding > crash-just-after-commit problem.
Right. I have this warning in the current docs for django-transaction-hooks, though it should probably be more prominent. I'll make sure it gets into the eventual Django patch, too. Carl
signature.asc
Description: OpenPGP digital signature
