manage.py runserver creates django_migrations without concent

[jorgecarleitao]

When you run ./manage.py runserver on a database without django_migrations table, the command issues a CREATE to create the table.

While this seems natural for users trying to run the server the first time, I would not expect a database interaction (specially a CREATE statement) from a runserver. The user is not being informed that the database is being changed.

At least, this should be mentioned in the documentation, but IMO it is odd that a runserver is issuing CREATE statements.

Of course, this is a consequence of not running manage.py migrate before.

[Andreas Madsack]

reproduceable on trunk

[Andreas Madsack]

The MigrationRecorder seems to create the table if it doesn't exist.

see: ​https://github.com/django/django/blob/master/django/db/migrations/recorder.py#L43

[Markus Holtermann]

I don't see a reasonable way to prevent Django from creating this table. But you are right, this should be documented.

[Andreas Madsack]

​https://github.com/django/django/pull/3515

[Tim Graham <timograham@…>]

In 27c9b3a27d313e75732c1e8e966b320ddbde499d:

Fixed #23808 -- Documented that migrations table is created when using runserver without migrating first.

[Tim Graham <timograham@…>]

In 7796f62c36555569125f8bb00cfb8b84b6da4eec:

[1.7.x] Fixed #23808 -- Documented that migrations table is created when using runserver without migrating first.

Backport of 27c9b3a27d313e75732c1e8e966b320ddbde499d from master

[Marti Raudsepp]

Discussion for an alternative solution here: #27858

[Tim Graham <timograham@…>]

In fda55c71:

Fixed #27858 -- Prevented read-only management commands from creating the django_migrations table.

MigrationRecorder now assumes that if the django_migrations table
doesn't exist, then no migrations are applied.

Reverted documentation change from refs #23808.