Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#23256 closed Bug (duplicate)

Changes in Meta class are not detected after "makemigrations"

Reported by: Manuel Kaufmann Owned by: nobody
Component: Migrations Version: 1.7-rc-2
Severity: Release blocker Keywords:
Cc: Manuel Kaufmann, Areski Belaid Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I found that adding "permissions" to the Meta class into a model and then removing these Meta class makes django migration system to be confused and it tries to create a new migrations with an empty "options" dictionary each time that "makemigrations" is ran.

Steps to reproduce:

  1. Create a new project
  2. Create a new app
  3. Install the app in the project
  4. Run "migrate"
  5. Create a new model
    class MyModel(models.Model):
        name = models.CharField(max_length=32)
    
  6. Run "makemigrations"
  7. Run "migrate"
  8. Add Meta class to MyModel
    class MyModel(models.Model):
        name = models.CharField(max_length=32)
    
        class Meta:
            permissions = (
                ('use_mymodel', 'Use this model'),
            )
    
  9. Run "makemigrations" and you will get the "options" attribute in the migration file
    operations = [
            migrations.AlterModelOptions(
                name='mymodel',
                options={'permissions': ((b'use_mymodel', b'Use this model'),)},
            ),
        ]
    
  10. Run "migrate"
  11. Remove Meta class from MyModel
    class MyModel(models.Model):
        name = models.CharField(max_length=32)
    
  12. Run "makemigratios" and you will get an empty "options" dictionary
    operations = [
            migrations.AlterModelOptions(
                name='mymodel',
                options={},
            ),
        ]
    
  13. Run "migrate"
  14. Run again "migrate" and you will get this message:
    Your models have changes that are not yet reflected in a migration, and so won't be applied.
    Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
    
  15. Run "makemigrations" again and the same migration file is created with empty "options" dictionary
    class Migration(migrations.Migration):
    
        dependencies = [
            ('myapp', '0002_auto_20140807_1242'),
        ]
    
        operations = [
            migrations.AlterModelOptions(
                name='mymodel',
                options={},
            ),
        ]
    

Now, every time you run "migrate" it will tells you that "your models have changes that are not yet reflected in a migration" and after running "makemigrations" you will get the same migrations every time. So, you never get to a state valid for Django Migration System.

I'm attaching a project with all the steps already done, from where you just simply can run "migrate" and "makemigrations" many times to see what I described here.

Attachments (1)

mymigrationstest.tar.bz2 (6.4 KB ) - added by Manuel Kaufmann 10 years ago.
Project to reproduce this issue

Download all attachments as: .zip

Change History (8)

by Manuel Kaufmann, 10 years ago

Attachment: mymigrationstest.tar.bz2 added

Project to reproduce this issue

comment:1 by Simon Charette, 10 years ago

Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted
Version: master1.7-rc-2

comment:2 by Manuel Kaufmann, 10 years ago

Summary: Changes in Meta class don't detected after "makemigrations"Changes in Meta class are not detected after "makemigrations"

comment:3 by Areski Belaid, 10 years ago

It seems to affect django-1.7-rc-2.
I tested this with last django master (https://github.com/django/django/commit/f9f9f3ad6073c353af924ed90c9386efd7bde8ac) and the bug seems to be solved.

@humitos, could you retest on master?

comment:4 by Areski Belaid, 10 years ago

Cc: Areski Belaid added

comment:5 by Baptiste Mispelon, 10 years ago

Resolution: fixed
Status: newclosed

I bisected the issue and found that it was fixed in 394053ce605a30c742d6270a80986b255adb3a30.

Thanks for doing the legwork on this.

in reply to:  3 comment:6 by Manuel Kaufmann, 10 years ago

Replying to areski:

@humitos, could you retest on master?

Yes, thanks. It's working on "master". I got confused about the version I was using. Actually, I was using 1.7c2 to be specific.

comment:7 by Collin Anderson, 10 years ago

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