#27110 closed Bug (fixed)
makemigrations shouldn't create `django_migrations` table in external databases
| Reported by: | direx | Owned by: | Tim Graham |
|---|---|---|---|
| Component: | Migrations | Version: | 1.10 |
| Severity: | Release blocker | Keywords: | regression |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
In Django 1.10 the makemigrations command creates a database table django_migrations in all databases defined in settings.DATABASES. In Django 1.9 and earlier this was not the case.
This behavior is bad if no (or only unmanaged) models reside in these databases. In my case I have quite a lot of databases defined in settings.DATABASES to be able to connect to them in a unified way. I only do raw SQL in there, so Django should not mess with these databases (or worse, introduce schema changes in third-party databases, like Django 1.10 does).
This is somewhat related to Bug #27054, although the fix provided there does not solve the issue. This regression is introduced by 02ae5fd31a56ffb42feadb49c1f3870ba0a24869.
Change History (8)
comment:1 by , 8 years ago
| Component: | Uncategorized → Migrations |
|---|---|
| Owner: | changed from to |
| Severity: | Normal → Release blocker |
| Status: | new → assigned |
| Summary: | [regression] makemigrations creates `django_migrations` table in external databases → makemigrations shouldn't create `django_migrations` table in external databases |
| Triage Stage: | Unreviewed → Accepted |
| Type: | Uncategorized → Bug |
comment:2 by , 8 years ago
| Has patch: | set |
|---|
comment:3 by , 8 years ago
An alternate proposal about consulting database routers is under discussion in #27142. It would be nice to have some confirmation that it solves your use case.
PR