#24067: Renaming Models asks for double confirmation (and doesn't preserve
relationships?)
----------------------------+--------------------------------------
Reporter: doepunk | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+--------------------------------------
Description changed by doepunk:
Old description:
> When renaming a model (from OldModel to NewModel) I noticed that
> makemigrations asks for confirmation if I had renamed NewModel to
> OldModel. Which is great that that was detected and the confirmation
> helps to get a correct migration file, which makes this step
> reproducible. The Model in question did not involve any foreign keys to
> or from it. However when I ran the migrate, I got this message
>
> {{{
> The following content types are stale and need to be deleted:
>
> <app-name> | <old-name>
>
> Any objects related to these content types by a foreign key will also
> be deleted. Are you sure you want to delete these content types?
> If you're unsure, answer 'no'.
> }}}
>
> I'm unsure what's going on here. But shouldn't renaming involve the
> automatic deletion of the old name and replacing the foreign keys with
> the new database table keys? All without a need for confirmation. Or at
> least if there are no foreign keys as in my case, the confirmation seems
> unnecessary and it only makes it harder to run the migration unsupervised
> and it introduces a potential error source. Assuming that all data from
> the old table were copied to the new table and all foreign key
> relationships copied and updated as well, I don't see a use case for
> keeping the old table and "related objects" around. And as for the case
> that there were any changes in relationships reflected in the Models
> (other than the name change) this could be detected and confirmed in the
> makemigrations stage. (For example if there were still references to
> OldName in the code when OldName no longer exists as a class, this would
> result in a syntax error, or if a Foreign Key attribute to OldModel was
> deleted and not replaced with NewModel Foreign Key it's just akin to a
> field deletion). It just seems more reproducible to keep all
> confirmations in the makemigration stage.
New description:
When renaming a model (from OldModel to NewModel) I noticed that
makemigrations asks for confirmation if I had renamed NewModel to
OldModel. Which is great that that was detected and the confirmation helps
to get a correct migration file, which makes this step reproducible. The
Model in question did not involve any foreign keys to or from it. However
when I ran the migrate, I got this message
{{{
The following content types are stale and need to be deleted:
<app-name> | <old-name>
Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.
}}}
I'm unsure what's going on here. But shouldn't renaming involve the
automatic deletion of the old name and replacing the foreign keys with the
new database table keys? All without a need for confirmation. Or at least
if there are no foreign keys as in my case, the confirmation seems
unnecessary and it only makes it harder to run the migration unsupervised
and it introduces a potential error source. Assuming that all data from
the old table were copied to the new table and all foreign key
relationships copied and updated as well, I don't see a use case for
keeping the old table and "related objects" around. And as for the case
that there were any changes in relationships reflected in the Models
(other than the name change) this could be detected and confirmed in the
makemigrations stage. (For example if there were still references to
OldName in the code when OldName no longer exists as a class, this would
result in an exception, or if a Foreign Key attribute to OldModel was
deleted and not replaced with NewModel Foreign Key it's just akin to a
field deletion). It just seems more reproducible to keep all confirmations
in the makemigration stage.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24067#comment:2>
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.7e59454286a7fa11fa7e098720724a29%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
