Migrations for multiple Django versions

[Vlastimil Zíma]

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

[Tim Graham]

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.

[Vlastimil Zíma]

Is that an official solution for migrations based on Django version?

Probably works, but it doesn't look like a nice solution.

Regards,
Vlastimil

Dne středa 19. října 2016 1:57:25 UTC+2 Tim Graham napsal(a):

[Vlastimil Zíma]

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.

[Tim Graham]

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

[Vlastimil Zíma]

I don't think separate migrations would make the problem any better, that looks just like more complicated implementation of migrations with condition in it.

Our use case:
Our webs consist from several projects based on Django, with dependencies between them. One of the core projects provides, among other things, custom user model for some of our applications. Given the experience we had with transition to newer Django in past we agreed to move to newer versions gradually, that is first support new version then drop the old one. Sadly there seems to be number of issues related to migrations which makes it quite hard.

Personally I think, the problem lies in migrations generated for `AbstractBaseUser`. Any changes in `AbstractBaseUser` model should result in migrations for `AUTH_USER_MODEL` instead of `auth.User` model directly. That should solve the problems with migrations on custom user model.

Or alternatively, let us redefine model fields inherited from parent class when we know what we're doing. IMHO warning should be enough, reporting error is not necessary.

Vlastimil


Dne čtvrtek 24. listopadu 2016 15:30:27 UTC+1 Tim Graham napsal(a):

[Dan Tagg]

Hi Vlastimil, 

Why not use your source control system to publish different releases for different versions of django.

Dan

--
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 django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
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/030257ec-f6b3-40b8-be7c-0a719c346133%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Wildman and Herring Limited, Registered Office: Sir Robert Peel House, 178 Bishopsgate, London, United Kingdom, EC2M 4NJ, Company no: 05766374

[Vlastimil Zíma]

According the documentation, migrations should be backwards compatible, see https://docs.djangoproject.com/en/1.9/topics/migrations/#supporting-multiple-django-versions. Hence there shouldn't be any reason to make different versions of any application for different versions of Django. Also I can't quite imagine how it would be helpful - it looks like another variation on "migration based on Django version" theme.

Vlastimil

Dne pátek 25. listopadu 2016 11:15:55 UTC+1 Dan Tagg napsal(a):

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
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/030257ec-f6b3-40b8-be7c-0a719c346133%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.