#32787: ContentTypes are created instead of renamed when using
SeparateDatabaseAndState
------------------------------------------------+------------------------
Reporter: David Seddon | Owner: nobody
Type: Bug | Status: new
Component: contrib.contenttypes | Version: 3.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
When renaming a model using `SeparateDatabaseAndState`, rather than
renaming the existing `ContentType`, a new one is created. This breaks any
existing generic foreign keys pointing to the model.
**Cause**
When a model is renamed in the standard way, the content types framework
uses the pre_migrate signal to rename the `ContentType` model, ensuring
that existing generic foreign keys continue to work. Code here:
https://github.com/django/django/blob/main/django/contrib/contenttypes/management/__init__.py#L79
If `SeparateDatabaseAndState` is used to control the migration, the
`isinstance` check will miss the fact that there is a `RenameModel`
operation, as it just checks the containing `SeparateDatabaseAndState`
operation. It therefore fails to inject a `RenameContentType` operation.
Later in the migration process, in
[https://github.com/django/django/blob/main/django/contrib/contenttypes/management/__init__.py#L105
create_contenttypes] will be triggered by the `post_migrate` signal. Since
there is now a missing ContentType for the new model name, it will create
it.
**Discussion**
While `SeparateDatabaseAndState` is of course meant to be a low level
operation, it's difficult to anticipate this behaviour. Since the
ContentTypes table is being changed by in any event, it would seem to me
preferable to do it in a backward-compatible way.
Alternatively, emitting a warning might be worthwhile: the developer could
then manually add a `RenameContentType` to the migration file once they're
aware of the issue.
I think this could be solved by adjusting
[https://github.com/django/django/blob/main/django/contrib/contenttypes/management/__init__.py#L105
the check] so that it drills down to the `database_operations` if the
operation is a `SeparateDatabaseAndState` instance.
--
Ticket URL: <https://code.djangoproject.com/ticket/32787>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/051.f070ebbd799e932b68bd8abf2d50b6d3%40djangoproject.com.
