Altering migration operations depending django.Version (3rd party apps)
178 views
Skip to first unread message
Patrick Craston
unread,
Apr 22, 2015, 7:32:48 AM4/22/15
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to django-d...@googlegroups.com
Hi all
I'm creating a migration for a 3rd party app that needs to work with
current and previous Django versions. In Django 1.8 "makemigrations" adds a
"AlterModelManager" operation which only works with Django 1.8 and
later since AlterModelManager didn't exist before. It will also do an AlterField to convert the IPAddressField to GenericIPAddressField.
Basically I append to migrations operations if django.VERSION >= (1,8). But as was mentioned in #django IRC, if the user applies the app's migration in Django 1.7 those migrations don't get applied. If the user then upgrades to Django 1.8, the user would miss those migrations?
Is there a
recommended way of altering migration operations depending on
django.VERSION? If yes, do you think it might be worth adding a note in the documentation?
Thank you! Patrick
Tim Graham
unread,
Apr 22, 2015, 8:13:40 AM4/22/15
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to django-d...@googlegroups.com
The recommended way is to run makemigrations with the lowest version of Django you wish to support. As this recommendation hasn't been tested, let us know if you encounter any problems with it. A potential problem that comes to mind is if you have an EmailField which had its default max_length increased to 254 characters in 1.8. If you run makemigrations using 1.7, you won't get a migration to increase the length of that column. The best solution is probably to add an explicit max_length=254 to such fields.
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to django-d...@googlegroups.com
Hi Tim
If I create a migration on the lowest Django version I wish to support (say 1.7), it will not add the AlterModelManager operation to the migration. If someone installs the app on Django 1.8, the migration will run fine.
However, every time the user runs "migrate" after that it will complain about the models having changes that are not reflected in a migration and ask the user to run "makemigrations" which doesn't seem right?
Tim Graham
unread,
Apr 22, 2015, 9:39:30 AM4/22/15
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to django-d...@googlegroups.com
makemigrations shouldn't automatically add model managers to migrations files. Did you opt them in with `use_in_migrations = True`? If so, I believe you have to drop compatibility with Django 1.7 (i.e. are you limited to the migrations feature set of the lowest version of Django you wish to support).