On Monday 20 July 2015 18:47:07 Carl Meyer wrote: > > > >> Personally I don't really see much use case for this feature > >> except as a workaround for reusable apps that generate spurious new > >> migrations based on settings changes > > > > I've also seen it with apps that use "EmailField" without specifying > > explicit length (which I'd expect to be the common way to use it...) > > Why would this cause a spurious new migration? >
It's arguably a bug in the reusable app. The app supported Django 1.7. Then they wanted to support Django 1.8, and its change of the default length of EmailField. So they added a migration that enlarges the field from 75 to 254. This actually makes a lot of sense for anybody upgrading from 1.7 to 1.8. However, if you use it with 1.7, makemigrations wants to add a migration to pull it back down to 75. I'm not sure what the reusable app was supposed to do here. They could drop support for 1.7 (or limit it to the older branch). They could make a separate release for each of the versions, differentiated only by the presence of the migration file. They could specify explicitly one of the lengthes, which would make their EmailFields incompatible with other default EmailFields (if there is ever reason to copy values from a field in one model to another, and these things do happen). None of these options are without prices. Even detecting the Django version in the migration and picking the length accordingly is problematic (if the migration is run before the Django upgrade, it will miss its purpose). The bug in the app is still open: https://github.com/omab/python-social-auth/issues/622 Shai.
