On Thursday 31 December 2015 06:31:40 Gavin Wahl wrote:
> I understand that a database is invalid or invalid as a whole, which is why
> you don't need to check constraints until transaction commit (when the
> transaction becomes visible to the world). Why do you want to bundle
> constraint checking with a savepoint release though? They seem logically
> unrelated. Wouldn't a standalone way to check deferred constraints be more
> useful?
>
It makes some sense to check constraints at the end of a set of operations
which are defined as a unit of work.
At the database level, it is mandatory at a transaction's end, and makes more
sense at a savepoint release than at an arbitrary point in the transaction
(although it does make sense elsewhere).
At Python code level, we use the same construct (atomic() block) for
transactions and savepoints, so it would make sense to allow them to behave in
similar ways. It is also arguable that any place where you'd want to check
constraints signifies the end of a unit of work, and so we should encourage the
uise of atomic() to also specify the beginning of said unit.
And then, there's "there should be one obvious way to do it", which hints we
should avoid having both check-in-atomic and check-independently.
My 2 cents,
Shai.
