Hi all,
I am migrating a complete dataset to a new database instance using dumpdata and loaddata. After doing it, I find that I don’t have entries in the ContentTypes table that should have been created because I can see ‘showmigrations’ has run for those apps, and the tables exist etc.
I think what has happened is that the ContentTypes table from the legacy database had some rows for apps that we’ve abandoned. So in initial setup, the migrations are run and the post-migration-trigger adds the entries for contenttypes e.g.
11 Polls Question,
12 Polls Answer,
13 Knowledge Reason
14 Drawings Drawing
When I bring the data from the legacy database, it has contenttypes only for
12 Polls Question,
13 Polls Answer,
14 Knowledge Reason
Earlier history of the site we had a different contenttype 1, which has been abandoned. The loaddata command overwrites the contenttypes table by row number (id is the pk) and I now have no contenttype for Drawing.
Since the source data is all referring to contenttypes on the old numbering scheme, I don’t think I’ve created data integrity errors, but I do need contenttype entries for all the current contenttypes. Possible solution directions:
- migrate --fake (not sure if post-migration things are triggered on ‘fake’ though)
- manually creating the rows for each app_label and model combination. This seems easy?
- revert and reapply migrations for the apps, but this will drop the tables and the data which I will have to work out how to reload.
I think the ideal solution would be for ContentTypes to dump and load by natural key (and natural_foreign when other things refer to them), or for the pk to actually be (app_label, model) but most of the other objects won’t respond to natural key serialization.