Fixed #33563 -- Fixed contenttype reverse data migration crash with a multiple databases setup.

[giff-h]

The ContentType legacy name field population operation would run on the
"default" database regardless of any specified alias

---

Found this while going through our code to ensure that it would smoothly run database restore operations on a given alias. It didn't cause any issues, I only found it by grepping our installed packages for migration operations to see if I should open any fix PRs.

[github-actions]

Hello @hamstap85! Thank you for your contribution 💪

As it's your first contribution be sure to check out the patch review checklist.

If you're fixing a ticket from Trac make sure to set the "Has patch" flag and include a link to this PR in the ticket!

If you have any design or process questions then you can ask in the Django forum.

Welcome aboard ⛵️!

[giff-h]

I have ensured that the test passes in both parallel and non-parallel mode without corrupting the rest of the suite, as well as fails on the unfixed migration code in both parallel and non-parallel mode without corrupting the rest of the suite

[felixxm]

@hamstap85 Thanks for the patch 👍 Welcome aboard ⛵

I added an alternative regression test to avoid migrate calls and possible isolation issues. What do you think?

[giff-h]

@felixxm oh I like that, very nice.

I had seen how tests/runtests.py sets the following

settings.MIGRATION_MODULES = {
    ...
    "contenttypes": None,
    ...
}

So I spent most of my time trying to fight with it to get the actual migration operation to run, but I hadn't considered importing the object by string lookup. I'm still not completely familiar with the idea of importing a module that isn't a top-level import keyword though I understand how it works.

So with self.assertRaises(AttributeError): would fail without the fix because it would attempt to set on the default db that time, and with no ContentType objects the loop would run 0 times.

[felixxm]

So with self.assertRaises(AttributeError): would fail without the fix because it would attempt to set on the default db that time, and with no ContentType objects the loop would run 0 times.

Exactly 👍

[charettes]

The testing approach is clever but I wish we had better testing facilities for migrations in general. It was proposed a few times on the developer mailing list but this is a good example of why a testing utility that would allow for tests to be executed in a context where some migrations are applied and other aren't on different databases would be useful.