Closed vtbassmatt closed 9 years ago
I am seeing a similar issue however I don't believe it is triggered to a settings change. With no changes to the code base I get migrations being produced for different apps. I ran:
git clean -f
manage.py makemigrations
git clean -f
manage.py makemigrations
and saw two different results:
Migrations for 'bookings':
0014_auto_20150407_1055.py:
- Alter field price_currency on bookingticket
Migrations for 'providers':
0016_auto_20150407_1056.py:
- Alter field price_per_click_currency on provider
- Alter field cost_currency on providerreferral
If I run makemigrations
several times with no changes to the code base I see the same results as @vtbassmatt
I've investigated this a bit and the origin of the issue is that the choices array for a CurrencyField is generated. In the end the list passed on the choices argument is different for the new and old field (they have different ids as reported by id()), causing the Django 1.7 migration code to believe that it has changed.
Noting that the issue is not reliable. It doesn't happen every time you run makemigrations
for each field.
Ok, found the cause: forms/widgets.py orders the currency by name. moneyed
has two different currencies with the name Kwacha
for the Malawian Kwacha (MWK) and the Zambian Kwacha (ZMK). So when CURRENCY_CHOICES
is built the sort will not always produce the same list.
I would argue that this is actually a bug in moneyed
, as the name should be the only thing visible to the user and, as such, should be unique.
django-money
could implement a workaround by changing the line in forms/widget.py
from CURRENCY_CHOICES.sort(key=operator.itemgetter(1))
to CURRENCY_CHOICES.sort(key=operator.itemgetter(1, 0))
.
If you are not using one of the currencies above you might just remove it using CURRENCIES
on your settings.py
.
Opened an issue with moneyed
: https://github.com/limist/py-moneyed/issues/55
Thanks - sounds good.
Thanks for opening up the other issue and getting it fixed in moneyed!
I have a money field defined in what I think is the normal way:
AbstractBaseModel
does some user and date bookkeeping for me.I'm using Django 1.7.3 on Python 3.4.2. Every so often, without me changing anything in any of my models.py files, manage.py will inform me that I have migrations I need to make. Only my money field will get a migration, and it'll be a differently-ordered but semantically equivalent of exactly what was there before.
File 0006_auto_20150125_1600.py:
and then file 0007_auto_20150125_1815.py:
I pulled the
choices
fields into the Python shell. ranset()
over them, and they compare identically. As far as I can tell, this is just a serialization hiccup.I haven't entirely root-caused the issue, though I think it may be every time I make certain changes in settings.py. (But not any change in settings.py, which is why it's been frustrating to track down.)
Has anyone else seen this, or do the core devs know what's going on? It's essentially a nuisance, not a "real" bug, but it would be nice to stop cluttering up my migrations folder with meaningless AlterFields. Thanks in advance!