Context Navigation

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

v3	v4
3	3	> The post_delete signal is explicitly sent within the same transaction as the actual deletion to ensure database changes performed in the receivers are tied to the transaction.
4	4
5		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.
	5	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, which is technically true but a bit misleading since it could exist again almost immediately.
6	6
7	7	> If you need to perform changes once the deletion of objects is committed you should use transaction.on_commit to defer their execution.