Wrażenia z aktualizacji młodego projektu do Django 1.7

Share

Od piątku możemy cieszyć się beta wersją Django 1.7. Nowa wersja frameworka wprowadza wiele ciekawych zmian, w tym własny system migracji zastępujący migracje South. W firmie mamy jeden młody projekt, który nie wyszedł jeszcze poza wersję rozwojową. Wykorzystaliśmy go jako królika doświadczalnego i przeszliśmy z Django 1.6 do 1.7a2 i obecnie 1.7b2. Proces te nie był zbyt skomplikowany, czy wybuchowy, ale wymagał też nieco czasu...

Migracje, testy i baza danych

Tak jak radzi dokumentacja usunąłem stare migracje i stworzyłem startowe fałszywe. Jedną migrację musiałem przepisać - migrację dodającą funkcje do bazy Postgresa. W tym celu stworzyłem w pliku migracji funkcję, która tworzyła je wykonując surowe zapytania SQL. Nowe migracje umożliwiają to dzięki liście operations i komendzie migrations.RunPython:

def do_something(*args, **kwargs):
    print('hi!')

class Migration(migrations.Migration):
    dependencies = []
    operations = [
        migrations.RunPython(do_something)
    ]

Co jeszcze fajne w nowych migracjach to to że naprawiły nam testy wykorzystujące owe funkcje postgresowe. W przypadku migracji South nawet z włączonymi migracjami w czasie testów tych funkcji w bazie nie było i testy padały. Tak więc problem został rozwiązany zanim potrzebny okazałby się jakiś hak (albo wyszukanie błędu w konfiguracji ;))

Pola BooleanField potrzebują też default=False bo inaczej domyślnie dostaniemy nulla. W starszym kodzie zapewne natrafimy na bezargumentowe BooleanFieldy, co nie będzie kompatybilne z nowszym Django.

Deploy

Nasz projekt używa Vagranta i pracujemy na konfiguracji jak najbardziej zbliżonej do produkcyjnej. Zamiast serwera deweloperskiego jest nginx, supervisor i gunicorn. Na Vagrancie dodatkowo działa sobie proces obserwujący zmiany w plikach i restartujący gunicorna gdy zajdzie potrzeba (albo collectstatic). Prosto po aktualizacji gunicorn całkowicie się wysypał i wyglądał jakoby byłby zupełnie niezgodny z nowym Django.

Pirwszą poprawką było odpalania go po nowemu - gunicorn MY_APP_NAME.wsgi:application zamiast gunicorn_django. Skrytym wysypywaczem gunicorna okazał się też django-debug-toolbar. Całkowite usunięcie DDT pozwoliło uruchomić się gunicornowi bez problemu. Oba źródła powodowały (na to wygląda) użycie gunicorn/app/django_wsgi.py, które jest przestarzałe i nie powinno być już używane (przy okazji niezgodne z Django 1.7).

Z mniejszych zmian w deploju aplikacji - znika south z aplikacji i zależności, jak i wywołanie syncdb. Polecenie migrate zostaje, ale jest już częścią Django, a nie Southa.

Na zakończenie

Jak na razie Django 1.7 działa bez problemów. Co prawda zbyt dużo django-zależnego kodu nie mamy, ale po zmianie z 1.6 na 1.7 nic nie wybuchło. Projekty z długą historią migracji, czy fixturami mogą mieć większą rozrywkę przy aktualizacji ;)

Share

Django, 23 March 2014