#33366: Migration autodetector doesn't handle placeholders in related_name for
ForeignKey.
-------------------------------------+-------------------------------------
Reporter: Andrew Chen Wang | Owner: Simon
| Charette
Type: Bug | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* needs_better_patch: 1 => 0
Comment:
Removing the ''patch needs improvement'' flag as I believe the noop
`AlterField` for the un-interpolated `related_name` is expected and
documented in the Django 4.0 release notes (see #32676).
I think the conclusion in comment:6 is wrong as I managed to reproduce the
''swappable'' dependency issue without involving `related_name` and the
noop `AlterField` manifestation on Django 4.0 can be achieved without
involving ''swappable'' models.
If we want to address the noop `AlterField` migration being generated for
all usages of placeholders in `related_name` there's two way we can do
that.
1. Augment the documentation to mention under which circumstances such
`AlterField` operations can be created and mention that it is safe to
adjust history migrations to use the proper ''placeholder'' syntax to
prevent it from happeing (it's safe even if your library supports Django <
4.0 as well because the models were rendered and thus `related_name` were
evaluated at field binding time).
2. Adjust the auto-detector to consider `'app_model` and
`'%(app_label)s_%(class)s'` equals (in the context of a `app.Model` model)
to prevent changes from being detected. This will have the unfortunate
side effect to prevent changes of a field from harcoded to placeholders
based `related_name` to be detected by the framework which could be
considered a limitation of the previous approach model rendering based
approach.
I personally think that 1. is the way to go but I don't have a strong
feeling here.
--
Ticket URL: <https://code.djangoproject.com/ticket/33366#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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/074.94d73f81e6f12317de4c9fc53c575244%40djangoproject.com.
