{{{
django.db.migrations.migration.IrreversibleError: Operation <RenameModel
new_name='NewModel', old_name='OldModel'> in <migration-name> is not
reversible
}}}
I consider this a bug, because I think renaming a database table to an old
name should not result in failure.
Another thing I noticed in that context is that when I originally did the
makemigrations to the NewModel name, I was asked if I had renamed, the
OldModel, which is great. However when I ran the migrate, I was told this
{{{
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24062>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* needs_better_patch: => 0
* resolution: => duplicate
* needs_tests: => 0
* needs_docs: => 0
Comment:
The model renaming request is a duplicate of #22248 which has been fixed
in the yet to be released 1.7.2.
Not sure if we can automate the renaming of content types, but we could at
least document this consideration. Please create a separate ticket,
thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/24062#comment:1>