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 
> 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 post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

Reply via email to