#24037 closed Bug (fixed)
Migrating a legacy table results in data loss
| Reported by: | Bibhas C Debnath | Owned by: | Tim Graham |
|---|---|---|---|
| Component: | Migrations | Version: | 1.7 |
| Severity: | Release blocker | Keywords: | |
| Cc: | Simon Charette | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
I created several models for our legacy database using inspectdb and hence all those models had their managed flag set to False. Now I need to make some changes to that model, hence I removed the managed flag and the generated migration wants to drop my table first and then create it again. Which leads to loss of all my data.
So I edited the migration file and removed the DeleteModel operation. And faked that migration to avoid the error raised by CreateModel as the table already exists.
But now I cannot go backward beyond that migration as the backward operation of CreateModel will drop my table anyway and there is no way to make a migration irreversible or ask it Not to drop my table.
What would help in such cases is a way to handle the backward migration. So that I can either choose not to drop my table or raise an exception to make the migration irreversible. Or at least make the CreateModel operation irreversible. I found that the Operation class has a flag called reversible. But I could find no way to set it to False.
For now I've added a fake RunPython operation that returns None to make that migration irreversible, as suggested by Markus / here. But I'd love some way to handle it properly.
Change History (7)
comment:1 by , 11 years ago
| Cc: | added |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
| Type: | Uncategorized → Bug |
comment:2 by , 11 years ago
| Severity: | Normal → Release blocker |
|---|
Yes, precisely charettes. The related discussion on django-users is https://groups.google.com/forum/m/#!topic/django-users/w9aVT3NOpkM
comment:3 by , 11 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:5 by , 11 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:6 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Shouldn't the autodetector simply issue a
AlterModelOptionsto change the model state frommanaged=FalsetoTruein this case? This would be no-op at the database level.