I'm having trouble with a field that seems to sometimes not update. Just want to know if the following is unsafe on a Django model instance.
obj.field1 = True
obj.save()
obj.field2 = True
obj.save()
Since I'm not calling obj.update_from_db() is there any risk the second save resets/overrides field1 ?
There are no post_save hooks involved, the surrounding code is synchronous and the DB backend is PostgreSQL.
Also, is save() synchronous (in the sense that the DB update will happen before the function returns)?
.save() is generally speaking strictly synchronous. Which is to say that when you call .save(), the commit will succeed before the method returns (or it will fail and the method will throw an exception).
There are a few situations where you this won't necessarily be the case (but they're more towards the advanced side of use-cases):
with transaction.atomic() context - the .save() can succeed (and return!) but persistence doesn't get attempted until the end of the transactionDEFERRABLE INITIALLY DEFERRED constraint, Postgres will only persist the changes to that column at the end of the transaction.save() returns synchronously but your data fetching after-the-fact can see "wrong" data (different isolation levels will have different patterns to create this scenario). They're all related to reads happening concurrently with writes, so it's a problem you'd expect to find usually only at high volume and with low frequency. This isn't a problem with .save() itself, but rather a note that it's hypothetically possible that .save() works exactly as expected but with unexpected data reads during/afterwards.