Ticket #68 (closed defect: duplicate)

Opened 7 years ago

Last modified 7 years ago

When should the post_syncdb be sent?

Reported by: amccurdy Owned by: andrew
Priority: major Milestone:
Component: commands Version:
Keywords: Cc:


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.

Change History

comment:1 Changed 7 years ago by andrew

Indeed; someone on IRC also suggested a similar move of post_syncdb, so it's certainly got some weight behind it. There's also the option of adding a new post_south signal instead at the end.

comment:2 Changed 7 years ago by andrew

  • Status changed from new to closed
  • Resolution set to duplicate

Just noticed this is a duplicate of #55, essentially, since that's the solution I want, if this is going in. I'm closing this one and suggesting we move forwards on that, advising people that, if they want data to appear between to migrations, to write a data migration.

Note: See TracTickets for help on using tickets.