Internally django runs sql immediately or deferredly.
This lib rewrite standard sql and split some complex sql to two parts one of them go to immediate execution and second go to deferred execution. For example creation not null fields and unique constraints that require SHARE UPDATE EXCLUSIVE lock sql (deferred) that cannot to run together with ACCESS EXCLUSIVE lock sql (immediate) be safe.
As mostly constraints created deferred way it looks safe to preserve default django approach. However nice to keep option to switch approaches for a while.
Fix for https://github.com/tbicr/django-pg-zero-downtime-migrations/issues/48
Internally django runs sql immediately or deferredly.
This lib rewrite standard sql and split some complex sql to two parts one of them go to immediate execution and second go to deferred execution. For example creation not null fields and unique constraints that require
SHARE UPDATE EXCLUSIVElock sql (deferred) that cannot to run together withACCESS EXCLUSIVElock sql (immediate) be safe.As mostly constraints created deferred way it looks safe to preserve default django approach. However nice to keep option to switch approaches for a while.