[Django] #24037: Migrating a legacy table results in data loss
Django
-------------------------------+--------------------
Reporter: iambibhas | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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
[https://groups.google.com/forum/#!topic/django-users/w9aVT3NOpkM / here].
But I'd love some way to handle it properly.
--
Ticket URL: <https://code.djangoproject.com/ticket/24037>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: iambibhas | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by charettes):
* cc: charettes (added)
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
* type: Uncategorized => Bug
* stage: Unreviewed => Accepted
Comment:
Shouldn't the autodetector simply issue a `AlterModelOptions` to change
the model state from `managed=False` to `True` in this case? This would be
no-op at the database level.
--
Ticket URL: <https://code.djangoproject.com/ticket/24037#comment:1>
Django
Reporter: iambibhas | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by MarkusH):
* severity: Normal => Release blocker
Comment:
Yes, precisely charettes. The related discussion on django-users
ishttps://groups.google.com/forum/m/#!topic/django-users/w9aVT3NOpkM
--
Ticket URL: <https://code.djangoproject.com/ticket/24037#comment:2>
Django
Reporter: iambibhas | Owner: timgraham
Type: Bug | Status: assigned
Component: Migrations | Version: 1.7
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => assigned
* owner: nobody => timgraham
--
Ticket URL: <https://code.djangoproject.com/ticket/24037#comment:3>
Django
Reporter: iambibhas | Owner: timgraham
Type: Bug | Status: assigned
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/3782 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/24037#comment:4>
Django
Reporter: iambibhas | Owner: timgraham
Type: Bug | Status: assigned
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/24037#comment:5>
Django
Reporter: iambibhas | Owner: timgraham
Component: Migrations | Version: 1.7
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"061caa5b386681dc7bdef16918873043224a299c"]:
{{{
#!CommitTicketReference repository=""
revision="061caa5b386681dc7bdef16918873043224a299c"
Fixed #24037 -- Prevented data loss possibility when changing
Meta.managed.
The migrations autodetector now issues AlterModelOptions operations for
Meta.managed changes instead of DeleteModel + CreateModel.
Thanks iambibhas for the report and Simon and Markus for review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24037#comment:6>
Django
Reporter: iambibhas | Owner: timgraham
Type: Bug | Status: closed
Severity: Release blocker | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"51ea30a43bafad40b4a24ad0be346796a9c7ab6a"]:
{{{
#!CommitTicketReference repository=""
revision="51ea30a43bafad40b4a24ad0be346796a9c7ab6a"
[1.7.x] Fixed #24037 -- Prevented data loss possibility when changing
Meta.managed.
The migrations autodetector now issues AlterModelOptions operations for
Meta.managed changes instead of DeleteModel + CreateModel.
Thanks iambibhas for the report and Simon and Markus for review.
Backport of 061caa5b386681dc7bdef16918873043224a299c from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24037#comment:7>