makemigrations shouldn't attempt to create django_migrations table

[Marti Raudsepp]

In multiple different projects now, I've needed to connect Django to legacy databases that aren't under Django's control. Even when setting "manage = False" in all affected models and configuring the DB router to never allow migrate in the legacy database, Django "makemigrations" still attempts to create the django_migrations table, causing permission errors in my use case.

The pull request changes MigrationRecorder is so that for read-only operations, if the django_migrations table doesn't exist, it's assumed that no migrations have been applied, instead of trying to create it. This applies to all migration commands.

Django has always had the problem of being "opinionated", meaning there's often fighting involved if you don't exactly follow The True Django Way. :) This patch is a small step in making Django more flexible.

PS: I understand that version 1.11 is already in a feature freeze, but is there aaaaany chance of getting this patch in there?

[Tim Graham]

I'm unsure about the steps to reproduce a problem here. According to #27054 it looks like if you configure Django properly, that table shouldn't be created. Do you have some configuration where that's not the case? (or is your patch meant to eliminate the need for such configuration?)

[Marti Raudsepp]

D'oh! You are right of course, it was a logic error in my allow_migrate method. That fixes my use case, thanks!

However, I still think the patch has some merit. It has always felt wrong to me that operations that should be entirely read-only, like makemigrations or runserver, go and start creating tables. Do you agree?