Django documentation about transaction points out:
Django uses transactions or savepoints automatically to guarantee the integrity of ORM operations that require multiple queries, especially
This means whenever we call
create(), it’s already wrapped in
a transaction. And usually new data is not in the database yet when we try to
get that again somewhere after.
To make sure it’s commited, we have to use
There are 2 popular cases I find that we must use
The first one is when we send task to a Celery queue. The error we usually made
here is to put that on a
post_save signal and hope for the best. Remember that
post_save is in the same transaction with
save(), so there is no guarantee
that new data will be in the database when Celery task get it from there.
We must use put the task to
on_commit() function like this:
The second case is when we want to do something after all inline forms in admin page is saved. But the thing we actually want is data is commited to database. You already know how to do it, just like the case above.
The catch here is we can put
on_commit() function in many places, as long as
it’s in the transaction. I usually put that on
depend on what extra infomation I need for further processing.