#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):
Thanks Andrew for the reply and for clearly laying out some options.
If I understand correctly, the only way out of this particular mess for
django-cms is to make BOTH the model field's choices point directly to
settings.CMS_TEMPLATES *and* the initial migration (and any subsequent
legitimate AlterField migrations) must also point to
settings.CMS_TEMPLATES to avoid tripping the autodetector.
django-cms indirectly gets choices from settings (tl;dr they first pass
the display names through ugettext_lazy and then point `choices` at the
resulting variable). All of which used to be completely legal
Django/Python/South but looks like they'll have to make some additional
backwards incompatible changes to accommodate Django 1.7, which will
likely delay compatibility for some time. The only other option for
django-cms that comes to mind is to move choices into ModelForm logic but
would have to think through the implications.
I get the mockery of choices pointing to querysets, but it's not so
obvious that the django-cms community did anything wrong using settings so
developers can define custom template choices (that in this case point to
real, version-controlled files on disk so database driven choices aren't a
good fit) and have these used in form rendering and validation (which is
primarily what help_text and choices are for). Is there a core-developer-
approved best practice for this sort of use case that wouldn't involve
pointing model field options at settings?
At any rate, not sure how widespread of an issue this might pose to the
wider ecosystem but do you think it's at least worth a clear warning in
the documentation for reusable apps authors?
--
Ticket URL: <https://code.djangoproject.com/ticket/23581#comment:14>
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.52a20fcc3c8e9f3e2f836b1ec01b9bac%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
