Assuming the problem is makemigrations generating different migrations based on the Django version, conditionally adding operations in migrations with some django.VERSION checks may help.
On Tuesday, October 18, 2016 at 7:12:02 AM UTC-4, Vlastimil Zíma wrote: > > Hi everyone, > > we are trying in our application to support multiple Django versions, > specifically 1.7 to 1.9. But we encountered a problem with > `User.last_login` field. We use custom User model based on > `AbstractBaseUser` as specified by the documentation. Everything was fine > in Django 1.7, but we got stuck when we wanted to add support for Django > 1.8, where the `last_login` was modified to allow NULL values. As > recommended by > https://docs.djangoproject.com/en/1.10/topics/migrations/#supporting-multiple-django-versions > > we have migrations generated in Django 1.7 (lowest supported version) an > thus `last_login` is NOT NULL, but that causes tests to fail when run in > Django 1.8/1.9, since code allows `last_login` to be NULL. > > We can't even redefine the field in our model, which would be the most > straight forward solution, but that's not allowed by Django either. > > What's the correct solution for this problem? It looks to us like there > are some unresolved issues regarding the model and migrations design. > > Thanks for any suggestions > Vlastimil > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/75892077-4a6f-4df3-a846-1f8f810fdb2d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
