Context Navigation

Changes between Version 2 and Version 3 of Ticket #30835, comment 2

-              v2
+              v3
 Ah.  I now understand why it is written the way it is.  But it is certainly not clear from the documentation that the {{{post_delete}}} signal is suitable only for other database activities and is unsuitable for things like sending a notification.  I do think that with a name like {{{post_delete}}}, it would be natural to assume that the deletion had actually been committed before sending the signal.  In fact, in the docs for {{{post_delete}}}, it explicitly says that the instance passed ''will not exist in the database'' at that point.
+> If you need to perform changes once the deletion of objects is committed you should use transaction.on_commit to defer their execution.
+Thanks, I didn't know about this.
 > Just to make sure I fully understand your report before closing this ticket, could you provide an example of your theory?
 I was trying to use it to send a notification.  So instance.delete() was called, a foreign key restraint failed, the transaction rolled back, and the deletion notification had already been sent.  I worked around it by writing my own signal and sending it after instance.delete() returned.
+I was trying to use it to send a notification.  So instance.delete() was called, a foreign key restraint failed, the transaction rolled back, and the deletion notification had already been sent.