#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 Arthur Rio):
>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? ​Someone give a
shot at permission renaming in #27489 and it seemed to be working fine.
The rationale was just to try to make things a bit less magical and show
the set of changes to the user instead of doing the injection behind the
scenes, but I hadn't considered the squashing and optimizations yet,
thanks for pointing that out. Thank you also for the references to
existing PRs that I can use as resources while working on this ticket.
It seems that the main issue blocking #27489 was to make sure the
permission operations injection happened **after** the contenttypes one.
What do you think about triggering a
`post_contenttypes_operations_injection` signal so that
`django.contrib.auth` can register to it and do its `create/update`
permission injection then? The `AlterModelOptions` operations injection
would happen in the `pre_migrate` though.
>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.
Sounds reasonable. Same for permissions I guess?
>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.
Thank you very much for your input, I will try the `pre_migrate` approach.
--
Ticket URL: <https://code.djangoproject.com/ticket/29843#comment:7>
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/065.085e54642e1229809d96a916cd6cceea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
