#29843: Create permissions using migration operations rather than using the
post_migrate signal
-------------------------------------+-------------------------------------
Reporter: Petter Strandmark | Owner: Arthur
Type: | Rio
Cleanup/optimization | Status: assigned
Component: contrib.auth | Version: 2.1
Severity: Normal | Resolution:
Keywords: contenttypes | Triage Stage: Accepted
permissions post_migrate |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette):
> Finally, I'm not sure yet how to handle adding django.contrib.auth and
django.contrib.contenttypes to the INSTALLED_APPS after migrations were
already created for other models, but I think that we could keep the
post_migrate signal in place to perform insert operations if 0001_initial
is part of the plan.
That's one of the reasons why `RenameContentType` operations are injected
in the plan on `pre_migrate` and not ''baked'' into migration files. We
must account for the fact these apps can be installed or uninstalled at
any time in the state of a project.
Another reason why operations baking is problematic is migration squashing
and optimizations which the operation injection technique completely works
around. I don't want to deter you from trying but I spent a large amount
of time working on the operation injection approach in #24067 and #24100
and it seemed like the best approach at least at that time. What's the
rationale for not using a similar approach for `CreateContentType`,
`CreatePermission` and `RenamePermission`?
[https://github.com/django/django/pull/6612/ Someone give a shot at
permission renaming] in #27489 and it seemed to be working fine.
Something to keep in mind as well is that an automatically generated
`DeleteContentType` operation could lead to data loss because of cascade
deletion of foreign references. That's the reason behind the interactive
`remove_stale_contenttypes` command. IMO that's a no go.
While I'm not a big fan of signals myself I can see how allowing third
party apps to ''bake'' operations could be useful. For example,
`contrib.postgres` could bake a `CreateExtension` if it detects an
`HStoreField` is first added to a project state. I just don't think this
is necessary to solve this issue as the operation injection approach seem
to be working fine.
--
Ticket URL: <https://code.djangoproject.com/ticket/29843#comment:5>
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/065.8d110b9f5dd11175d330e1c13a0a8610%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
