Ticket #68 (closed defect: duplicate)
When should the post_syncdb be sent?
|Reported by:||amccurdy||Owned by:||andrew|
I'm noting this problem in a ticket to make sure I remember it.
Currently, South sends a post_syncdb at the end of each migration. This can cause several ordering issues that are apparent when the signal handler chooses to work with models. In this case, the interaction may attempt to execute SQL using the newest model and field definitions, some of which may not have been applied to the schema yet.
For example, the django.contrib.contenttypes app listens to this signal for creating new/deleting stale content types. When deleting a content type, Django's default behavior is to also delete any rows in other tables that have a foreign key to the content type being deleted. If one of those tables also has pending migrations, Django's attempt to query rows from that table may fail if the model and table definition differs.
One possible fix to this would be to delay the post_syncdb signal until after *all* pending migrations (project wide) were run. This however comes with the side effect that data generated by post_syncdb handlers won't be available until some later, non-deterministic point.