I'm not sure. Possibly you could hack up a solution with separate migration directories for each Django version you want to support, e.g. migrations_dj19, migrations_dj18, ... and then point to the correct directory with settings.MIGRATION_MODULES. I'm doubtful if that can be done elegantly when upgrading from one Django version to the next (if each directory has different migrations) but maybe it inspires a solution.
Off topic, but I'm curious why you want to support multiple versions of Django with a custom user model. Usually when I see a use case for multiple Django version support it's for reusable apps, which shouldn't contain a custom user model. https://docs.djangoproject.com/en/stable/topics/auth/customizing/#reusable-apps-and-auth-user-model On Thursday, November 24, 2016 at 5:36:03 AM UTC-5, Vlastimil Zíma wrote: > > We find out migrations with condition on Django version doesn't work. > > Let's have migrations based on Django version for user last_login: > 1. Create database > 2. Run migrations in Django 1.7 - that correctly creates table > custom_user with last_login NOT NULL > 3. Update Django to 1.9 > 4. Run migrations -> migration for auth.User is correctly ignored > 5. custom_user with last_login is NOT NULL, altough it shouldn't be. Both > migrations that should take care of it were ignored - our migration because > it was based on Django version, auth migrations because the use is swapped. > > So, what now? > > Vlastimil > > Dne středa 19. října 2016 1:57:25 UTC+2 Tim Graham napsal(a): >> >> 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/b73c1914-adce-4326-9c27-d7ac38f59f1d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
