[Django] #27858: makemigrations shouldn't attempt to create django_migrations table
Django
------------------------------------------+--------------------------------
Reporter: Marti Raudsepp | Owner: Marti Raudsepp
Type: New feature | Status: assigned
Component: Migrations | Version: 1.10
Severity: Normal | Keywords: makemigrations
Triage Stage: Unreviewed | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------+--------------------------------
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 alreday in a feature freeze, but is
there aaaaany chance of getting this patch in there?
--
Ticket URL: <https://code.djangoproject.com/ticket/27858>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Marti Raudsepp | Owner: Marti Raudsepp
Type: New feature | Status: assigned
Component: Migrations | Version: 1.10
Keywords: makemigrations | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Marti Raudsepp:
Old description:
> 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 alreday in a feature freeze, but is
> there aaaaany chance of getting this patch in there?
New description:
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?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:1>
Django
Reporter: Marti Raudsepp | Owner: Marti Raudsepp
Type: New feature | Status: assigned
Component: Migrations | Version: 1.10
Keywords: makemigrations | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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?)
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:2>
Django
Reporter: Marti Raudsepp | Owner: Marti Raudsepp
Type: New feature | Status: assigned
Component: Migrations | Version: 1.10
Keywords: makemigrations | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Old description:
> 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?
New description:
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?~~
--
Comment (by 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:3>
Django
Reporter: Marti Raudsepp | Owner: Marti Raudsepp
Type: New feature | Status: assigned
Component: Migrations | Version: 1.10
Keywords: makemigrations | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* cc: Andrew Godwin (added)
Comment:
I can't think of any problems with that change. Andrew, what do you think?
Side note: #23808 reported the issue of `runserver` creating the
migrations table and the resolution was to document the behavior.
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:4>
Django
Reporter: Marti Raudsepp | Owner: Marti Raudsepp
Type: New feature | Status: assigned
Component: Migrations | Version: 1.10
Keywords: makemigrations | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Andrew Godwin):
Replying to [comment:4 Tim Graham]:
> I can't think of any problems with that change. Andrew, what do you
think?
Seems like a good idea to me, and the PR is quite small which is nice.
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:5>
Django
django_migrations table
-------------------------------------+-------------------------------------
Reporter: Marti Raudsepp | Owner: Marti
Cleanup/optimization | Status: assigned
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: makemigrations | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* cc: Andrew Godwin (removed)
* stage: Unreviewed => Accepted
* type: New feature => Cleanup/optimization
Old description:
> 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?~~
New description:
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:6>
Django
django_migrations table
-------------------------------------+-------------------------------------
Cleanup/optimization | Status: assigned
Component: Migrations | Version: 1.10
Severity: Normal | Resolution:
Keywords: makemigrations | Triage Stage: Accepted
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:7>
Django
django_migrations table
-------------------------------------+-------------------------------------
Cleanup/optimization | Status: closed
Component: Migrations | Version: 1.10
Severity: Normal | Resolution: fixed
Keywords: makemigrations | Triage Stage: Accepted
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"fda55c71a8846364b9dc4f4efac4d7034ef6dd6f" fda55c71]:
{{{
#!CommitTicketReference repository=""
revision="fda55c71a8846364b9dc4f4efac4d7034ef6dd6f"
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.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:8>
Django
django_migrations table
-------------------------------------+-------------------------------------
Cleanup/optimization | Status: closed
Severity: Normal | Resolution: fixed
Keywords: makemigrations | Triage Stage: Accepted
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"24d7fe49332614fd838cbccdd2b8e8aad0d37a71" 24d7fe49]:
{{{
#!CommitTicketReference repository=""
revision="24d7fe49332614fd838cbccdd2b8e8aad0d37a71"
Refs #27858 -- Fixed typo in MigrationRecorder.applied_migrations()
comment.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:9>
Django
django_migrations table
-------------------------------------+-------------------------------------
Cleanup/optimization | Status: closed
Severity: Normal | Resolution: fixed
Keywords: makemigrations | Triage Stage: Accepted
Easy pickings: 0 | UI/UX: 0
Comment (by Marti Raudsepp):
Thanks! And sorry! I always intended to get back to this, but kept
procrastinating. :(
--
Ticket URL: <https://code.djangoproject.com/ticket/27858#comment:10>