#23581: Migration shouldn't generate "DROP DEFAULT" SQL if no database changes
are
required
--------------------------------------+------------------------------------
Reporter: john_scott | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by john_scott):
I'm clearly missing something then. Yes I understand that these options
can affect data migrations, but neither choices nor default are used as
far as I've seen in schema migrations. And of course this ticket partly
exists because Django tries too hard to make sure a specified `default`
never results in database changes.
Apologies if I'm being thick but I'm still not getting a clear idea of
what users of django-cms (or any 3rd party app that lets users define
choices in settings) are supposed to do in the short term. Sorry to beat
this point into the ground but I don't own django-cms's migrations, I only
control my apps migrations. So even if it pointed to a settings attribute,
Django will still forcibly create a spurious migration in our local
virtualenvs (e.g. `env/src/django-cms`). As a result these migrations
won't be a visible part of our version controlled project. Are we expected
to dig these out, fork django-cms and commit/squash/merge migrations with
upstream? I mentioned above, this is doubly painful since anytime we
create a migration for our app, Django will forcibly create one of these
migrations for django-cms and then make our migration dependent on it. Our
current workflow is to manually delete Django's spurious migration from
our virtualenv and then edit our intended migration in our project so that
its dependency points to the last official django-cms migration and to
otherwise ignore Django's complaint about unmigrated changes. Which we
have to do every single time we create a migration.
It's also not clear what authors of reusable apps are supposed to do to
eliminate this pain point for their users. A *nuclear* option mentioned
was to subclass fields to `del kwargs['choices']` in the deconstruct
method, which is obviously not a desirable way out of this.
I've been banging my head against this and far too many other bugs lately
and am probably suffering from a bit of brain damage, so apologies if I'm
completely missing the obvious. Frustrations aside, endless thanks to
Andrew and others for their hard work on migrations support!
--
Ticket URL: <https://code.djangoproject.com/ticket/23581#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.43212c895823f1b58228197ae7b34dee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
