Ticket #55 (closed enhancement: fixed)

Opened 7 years ago

Last modified 6 years ago

post_syncdb signal is sent too early

Reported by: ero-sennin Owned by: andrew
Priority: major Milestone: 0.4
Component: databaseapi Version: 0.3
Keywords: Cc: densetsu.no.ero.sennin@…


Our app is listening to post_syncdb signal to load some initial data into the DB. The problem is, post_syncdb is sent right after the table is created, before any subsequenta migrations are applied. At that point the table in the DB is different from its description in models.py, so Django ORM fails complaining about missing columns. Would be nice if post_syncdb or some other signal was sent after completing all pending migrations.


delayed_post_syncdb.patch (1.5 KB) - added by ero-sennin 7 years ago.
a quick and dirty hack to send post_syncdb signals after all migrations have been executed

Change History

Changed 7 years ago by ero-sennin

a quick and dirty hack to send post_syncdb signals after all migrations have been executed

comment:1 Changed 7 years ago by andrew

  • Status changed from new to accepted

This is definitely an interesting patch, and one I'm not going to dive straight into, since people may (for some odd reason) rely on the existing behaviour. I'd like to know what Andy thinks of this, too.

I'd propose making this a toggleable option, and if it's on by default making it clear to people who are upgrading that this happens, and it might be weird.

A replacement proposal for this is a mode that just uses syncdb the first time, and then migrations there on (similarly to django-evolution), although that approach has its flaws, and does nothing about large upgrades after the first time, so I'm tending to prefer this.

comment:2 Changed 7 years ago by andrew

  • Version set to 0.3
  • Milestone set to 0.4

OK, I'm looking to include this in soon, since I see no reason not to; post_syncdb code is always expecting the newest models, since it's not really versioned. In future, if data needs to be added between two migrations, I'll be recommending writing a data migration for it.

comment:3 Changed 6 years ago by andrew

  • Status changed from accepted to closed
  • Resolution set to fixed

OK, patch committed in [126], with a few modifications related to dry runs. I'll add this to (the new) BackwardsIncompatableChanges, since it is potentially.

Note: See TracTickets for help on using tickets.