django upgrade 1.6 auf 1.11

Hier eine Zusammenfassung einiger Upgradeschritte die nötigen waren um ein django 1.6 Projekt auf django 1.11 upzugraden.

Migrations

In django 1.6 wurde in der Regel django south für Datenbankmigrationen benutzt seit Version 1.7 besitzt django selber Datenbankmigrationen.

Als erstes muss man alle eigenen south migrationen löschen z.B. mit

find . -type file|grep /migrations/ | xargs rm

1	find . -type file\|grep /migrations/ \| xargs rm

dies löscht alle migrations files im aktuellen folder und tiefer.

Als nächstes muss man die initialen migrations wieder anlegen, und fake migrations ausführen, da man die Tabellen nicht geändert

./manage.py makemigrations
./manage.py migrate --fake-initial

1 2	./manage.py makemigrations ./manage.py migrate --fake-initial

Falls man ein Custom User Model benutzt, muss man die column last_login manuell in der DB ändern, ansonsten kommt es zu startup Fehlern.

ALTER TABLE `userprofile_user`
CHANGE COLUMN `last_login` `last_login` DATETIME NULL;

1 2	ALTER TABLE `userprofile_user` CHANGE COLUMN `last_login` `last_login` DATETIME NULL;

Context, Render

Die Python Class RequestContext ist nicht mehr vorhanden. Alle imports müssen gelöscht werden.

from django.template.context import RequestContext # löschen

1	from django.template.context import RequestContext # löschen

Anstatt der Class RequestContext() kann man ein einfach ein dict() verwenden für den context

context = {}

1	context = {}

die imports, statements mit

from django.shortcuts import render_to_response # alt
...

    return render_to_response("appname/detail.html", context) # alt

from django.shortcuts import render_to_response # alt

...

return render_to_response("appname/detail.html", context) # alt

müssen ersetzt werden mit

from django.shortcuts import render # neu
...
    return render(request, "appname/detail.html", context) # neu

from django.shortcuts import render # neu

...

return render(request, "appname/detail.html", context) # neu

Named urls

Dies ist nicht zwingend nötig, aber bei diesem upgrade empfehle ich auch gerade auf named urls umzustellen. z.B.

... 
url(r'^logout/$', logout), # alt

1 2	... url(r'^logout/$', logout), # alt

auf

...
url(r'^logout/$', logout, name="userprofile.views.logout"),

1 2	... url(r'^logout/$', logout, name="userprofile.views.logout"),

string views habe ich alle in callables geändert z.b.

urlpatterns += static(settings.STATIC_URL, view='django.contrib.staticfiles.views.serve', show_indexes=True) # alt

from django.contrib.staticfiles import views as staticfiles_views # neu
urlpatterns += static(settings.STATIC_URL, view=staticfiles_views.serve, show_indexes=True) # neu

urlpatterns += static(settings.STATIC_URL, view='django.contrib.staticfiles.views.serve', show_indexes=True) # alt

from django.contrib.staticfiles import views as staticfiles_views # neu

urlpatterns += static(settings.STATIC_URL, view=staticfiles_views.serve, show_indexes=True) # neu

andere apps

Wenn man noch andere django apps benutzt kann es zum Teil schwierig sein diese zu migrieren:

manchmal gibt es auch keine neuere Version, und man muss die django app ersetzten
die Datenstruktur lässt sich nicht migrieren, manuelle Anpassungen können nötig sein

in diesem Projekt habe ich z.B.

django-mediagenerator durch django-compressor ersetzt

Reine Python packages lassen sich in der Regel einfach updaten.

Netzkompetenz