On Mon, Jul 20, 2015 at 11:56:40AM -0600, Carl Meyer wrote:
On 07/20/2015 11:47 AM, Shai Berger wrote: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 changesI'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/622I see, thanks for the explanation. ISTM that the best available solution for this situation is to specify the length of the field explicitly to 254. Yes, this means that a Django 1.7 user copying an email address from the social-auth email field to some other default-length email field might have to figure out what to do with emails longer than 75 characters, but a) that's not likely a common case, and b) such a user has the migration system available to just lengthen their own email field with an explicitly-specified length, too. Carl
The recommended way is to specify the length explicitly and use the lowest Django version to generate migrations you want to support. /Markus
-- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/55AD3658.5090902%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
-- -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20150723014647.GB3500%40pyler.local. For more options, visit https://groups.google.com/d/optout.
pgpQXtwOx5j0j.pgp
Description: PGP signature
