#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 django-updates+unsubscr...@googlegroups.com. To post to this group, send email to django-updates@googlegroups.com. 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.