Opened 3 years ago

Closed 21 months ago

Last modified 21 months ago

#24650 closed Cleanup/optimization (fixed)

Migration changing db_table and managed not creating new table

Reported by: Eduardo Klein Owned by: nobody
Component: Documentation Version: 1.8
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I had a model like this:

class Decoupe(models.Model):
    constante = models.IntegerField()

    class Meta:
        managed = False
        db_table = "Decoupe"

I ran the first migration and it recognized the options as expected.
Then I removed the meta options, so the model looked like this:

class Decoupe(models.Model):
    constante = models.IntegerField()

I ran make migrations and it created the following:

migrations.AlterModelOptions(
    name='decoupe',
    options={},
),

When I applied it, nothing really happened and of course, when, trying from the shell, to to Decoupe.objects.all(), I got an error saying that the table "myapp_decoupe" did not exits.

I would expect either the table to be renamed or at least created empty.

I tried to workaround this replacing the migrations above with

migrations.DeleteModel("decoupe"),
migrations.CreateModel( ... ),

But when I ran it, I got a error:
RuntimeError: Error creating new content types. Please make sure contenttypes is migrated before trying to migrate apps individually., although the contenttypes is migrated.

Is this a bug or desired behavior since the model was "managed=False"?

Change History (7)

comment:1 Changed 3 years ago by Eduardo Klein

Sorry, I was in django 1.7.

I also tried removing the "managed=False" from the initial migration and got the same contenttype error. I did not understand why, since I was not changing any content type.

I upgraded then to 1.8. The automatically generated migration was the same and applying it did not change a thing, so I think there is still an issue. Trying to delete and re-create the model as above raised the same error.

What did work was removing the "managed=False" from the initial migration. Django then renamed the table as expected.

Is it intended behavior that any model marked as "managed=False" should never be changed with django's migration?

comment:2 Changed 3 years ago by Tim Graham

If managed=False then you're saying that the table already exists, so I don't think changing it to managed=True should issue a CREATE TABLE. The contenttypes error is probably triggered because the table doesn't exist. Can you try doing it in two steps: remove managed=False, run makemigrations, then remove db_table and run makemigrations.

comment:3 Changed 3 years ago by Eduardo Klein

Thanks for your quick response.
Doing it in 2 steps worked in django 1.8 (I did not test in django 1.7).

Regarding the contenttype issue, the table (and the model) did exist. This issue does not appear in Django 1.8 anymore, so I'm not sure it's worth digging further.

Maybe it's worth mentioning in the docs that changing a model from the managed=False state to managed=True and making other changes should be done in 2 steps, as you suggested.

Thanks again.

comment:4 Changed 3 years ago by Markus Holtermann

Component: MigrationsDocumentation
Triage Stage: UnreviewedAccepted
Type: UncategorizedCleanup/optimization

comment:5 Changed 21 months ago by Tim Graham

Has patch: set

comment:6 Changed 21 months ago by GitHub <noreply@…>

Resolution: fixed
Status: newclosed

In 80c03b06:

Fixed #24650 -- Documented how to change an unmanaged model to managed.

comment:7 Changed 21 months ago by Tim Graham <timograham@…>

In 6be255a2:

[1.10.x] Fixed #24650 -- Documented how to change an unmanaged model to managed.

Backport of 80c03b06ad1461c1a07091806dc0414a4e98905e from master

Note: See TracTickets for help on using tickets.
Back to Top