makemigrations generates new migration when nothing has changed

[Francis Fisher]

Any idea why makemigrations would fail to recognise that a migration has already been generated?

makemigrations.py is a script which calls makemigrations with appropriate django settings. If I run this once, it will generate the initial migration, but every time I run it subsequently, it will regenerate a migration even though nothing has changed in the model. This is with django 1.10.3 and postgres. The field sk that is constantly regenerated is a foreign key relation to an unmanaged database, but I have referred to this in a different app with no bother.

I am using django 1.10.3.

I found a post in this group that had a similar issue with instantiating a class in the model that was missing an implementation for __eq__ but that doesn't apply in this case as I don't instantiate any class in the model file.

Is there any common mistake that leads to this outcome?

------------------

user@testenv:~/eit/testproj$ ./makemigrations.py 

Migrations for 'sk':

  testproj/sk/migrations/0001_initial.py:

    - Create model SKM

user@testenv:~/eit/testproj$ ./makemigrations.py 

Migrations for 'sk':

  testproj/sk/migrations/0002_auto_20161130_1643.py:

    - Alter field s on skm

user@testenv:~/eit/testproj$ 

user@testenv:~/eit/testproj$ ./makemigrations.py 

Migrations for 'sk':

  testproj/sk/migrations/0003_auto_20161130_1643.py:

    - Alter field s on skm

[Mike Dewhirst]

On 1/12/2016 3:56 AM, Francis Fisher wrote:
> Any idea why makemigrations would fail to recognise that a migration
> has already been generated?

I think migrations is seeing field choices differently each time it
scans the model. Can you use a list rather than a tuple for choices? (Or
vice versa - I don't remember) Or import the choices from another module?

> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/ad7c5eb6-4542-456e-8e53-675c02e897b1%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/ad7c5eb6-4542-456e-8e53-675c02e897b1%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Bruno A.]

I've seen that happening when calling a callable as one of the keyword argument rather than passing the callable itself. Typical example:

class TimeFramedModel(models.Model):

    created = models.DateTimeField(default=timezone.now())

Instead of:

class TimeFramedModel(models.Model):

    created = models.DateTimeField(default=timezone.now)

As Mike pointed out, in the case of a ForeignKey it might be with choices maybe?

[Francis Fisher]

On Wednesday, 30 November 2016 22:43:55 UTC, Mike Dewhirst wrote:

On 1/12/2016 3:56 AM, Francis Fisher wrote:
> Any idea why makemigrations would fail to recognise that a migration
> has already been generated?

I think migrations is seeing field choices differently each time it
scans the model. Can you use a list rather than a tuple for choices? (Or
vice versa - I don't remember) Or import the choices from another module?

Thanks for this suggestion - I am using a field with choices somewhere in the model referenced by a ForeignKey.

I tried switching the choices from a tuple of tuples to a list of lists, and I tried defining the choices in another module, I also tried entirely removing the choices argument from the field definition, however none of those actions resolved the issue. I've since tried this action with django 1.10.4 but to no avail.

[Mike Dewhirst]

I'm using 1.8 so I can't help there.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-users/a66060ed-5ae1-4517-a9bd-1dcdc6cb49f8%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/a66060ed-5ae1-4517-a9bd-1dcdc6cb49f8%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Tim Graham]

Try looking at the code in the autodetector and doing some some debugging to figure out how old_field_dec and new_field_dec are different:
https://github.com/django/django/blob/8db6a6c0a1c73bf08e71e00d4ab8c4af3c5f0cb8/django/db/migrations/autodetector.py#L911