Don't import plugin models in main migrations

[jmbowman]

While working on the switch from nose to pytest in edx-platform, I discovered that we import models from some of the wiki plugins in the main wiki app's migrations. We don't run migrations before starting tests, but we do have a test which verifies that we don't have model changes which aren't reflected in our migrations. And we don't actually use those plugins, so those models aren't found when preparing the database for a test run. So depending on exactly when this test is run, it can break subsequent tests which delete users because after importing those model files, Django now expects there to be tables for models in them which have foreign keys to user records.

Fixing this by doing the following:

• Edit the problematic migration to no longer import those model files, replacing the "upload_to" attributes that depended on functions from them with static strings instead.
• Add a new migration which deletes the tables for the plugin models, so makemigrations won't care about the fact that those field attributes changed.
• Add migrations to the plugins which are very close to what upstream is currently using, on the off chance we actually do start using these plugins someday.
• Borrowed some Django app configuration code from upstream to assign appropriate app labels to the plugins, as used in relationships in the migration files.

[doctoryes]

Couple of questions.

[doctoryes]

Just curious - do Django's automatically-generated migrations remove each field like this before deleting models?

[jmbowman]

I think these were just the foreign keys, removed separately to avoid referential integrity problems when dropping the tables. As I noted in my other reply, this is a fairly tangled pair of models.

[doctoryes]

Why the separateAddFields after the CreateModels? Is this just several migrations from upstream squashed together?

[jmbowman]

This is what was in our original 001_initial migration for the wiki app, copied over verbatim. This was a particularly tricky case because AttachmentRevision has a foreign key to itself, plus it and Attachment have foreign keys to each other. I think Django just erred on the side of caution and added each of the foreign keys individually after creating the tables.

[bmedx]

👍