Django 4.0 dostępny – opis nowości i zmian

Django to nadal najpopularniejszy, a według wielu także najlepszy pythonowy framework służący do prac nad aplikacjami webowymi. Swoją premierę ma właśnie kolejna duża wersja Django oznaczona numerem 4.0, do której zawitało kilka ważnych nowości i zmian. 

Zanim przyjrzymy się im bliżej, warto nadmienić, że Django 4.0 jest kompatybilny z Pythonem 3.8, 3.9 i 3.10. Porzucono zatem wsparcie dla gałęzi 3.6 i 3.7. Przed aktualizacją frameworku zaleca się rozwiązanie wszystkich ostrzeżeń o porzuconych funkcjach czy API, czego w środowisku testowym można dokonać poleceniem python -Wa manage.py test.

UniqueConstraint.expressions

Za najważniejszą nowość w Django 4.0 należy uznać dodanie nowego argumentu pozycyjnego *expressions dla klasy UniqueConstraint() służącej do tworzenia w bazie danych unikalnych ograniczeń. Dzięki *expressions możliwe jest odtąd korzystanie z unikalnych ograniczeń na wyrażeniach oraz funkcjach baz danych. W efekcie dzięki Django można np. upewnić się, że w jakiejś kolumnie bazy dana wartość nie występuje więcej niż raz. Prześledźmy to na przykładzie:

UniqueConstraint(
	Lower('name').desc(), 'category', 
	name='unique_lower_name_category',
	),

W tym przypadku zostanie utworzone unikalne ograniczenie na wartości pola name w porządku malejącym oraz na pole category w domyślnym porządku rosnącym. UniqueConstraint() w Django są dodawane do modeli w postaci opcji Meta.constraints, a zatem użycie unikalnego ograniczenia sprawdzającego, czy wartości imion i nazwisk dla modelu nie zostały zduplikowane przybierze następującą postać:

from django.db import models
from django.db.models import UniqueConstraint
from django.db.models.functions import Lower

class MyModel(models.Model):
    imie = models.CharField(max_length=255)
    nazwisko = models.CharField(max_length=255)

    class Meta:
        constraints = [
            UniqueConstraint(
                Lower('imie'),
                Lower('nazwisko').desc(),
                name='unikalne_imie_nazwisko',
            ),
        ]

scrypt

Kolejna nowość w Django 4.0 to zmiana funkcji skrótu. Odtąd do haszowania zamiast PBKDF2 wykorzystywana będzie scrypt. Decyzja podyktowana jest, a jakże, bezpieczeństwem. PBKDF2 wykorzystywała niewielką ilość pamięci, co jednak zmniejszało jej skuteczność w przypadku dużych ataków brute force. scrypt wykorzystuje do haszowania większą ilość pamięci, co może skutecznie spowolnić atak. 

Właśnie przez zwiększone zużycie pamięci oraz wymóg dostępności OpenSSL w wersji 1.1 lub nowszej scrypt w Django 4.0 jest domyślnie wyłączony. Można go włączyć dodaniem do PASSWORD_HASHERS w pliku konfiguracyjnym wpisu 'django.contrib.auth.hashers.ScryptPasswordHasher' na pierwszej pozycji. Po modyfikacji PASSWORD_HASHERS modyfikacji wyglądać powinno następująco: 

PASSWORD_HASHERS = [
    'django.contrib.auth.hashers.ScryptPasswordHasher',
    'django.contrib.auth.hashers.PBKDF2PasswordHasher',
    'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
    'django.contrib.auth.hashers.Argon2PasswordHasher',
    'django.contrib.auth.hashers.BCryptSHA256PasswordHasher',
]

zoneinfo

W nowym Django dokonano także zmiany w domyślnej implementacji stref czasowych. pytz zostało zastąpione przez zoneinfo, co stanowi odpowiedź na zmiany w samym Pythonie (zonfeinfo to standardowa biblioteka od wersji 3.9). pytz co prawda nie został jeszcze całkowicie usunięty z Django, ale stanie się to już wraz z premierą wersji 5.0. 

O ile zmiana wydawać się może mało istotna, to jednak może przysporzyć pewnych problemów w sytuacjach, kiedy wykorzystywane są strefy czasowe spoza list uniwersalnego czasu koordynowanego. Wówczas konieczne będzie wprowadzenie w kodzie zmian. Tymczasowym rozwiązaniem (zostanie usunięte w Django 5.0) jest modyfikacja pliku konfiguracyjnego. Dla wpisu USE_DEPRECATED_PYTZ należy ustawić wartość na true.

Redis

Framework oferuje odtąd wbudowane wsparcie dla Redisa, który wykorzystywany może być do cachowania. Po uruchomienia serwera Redis (wymagana jest wersja 3.0.0 lub nowsza) należy wprowadzić zmiany w konfiguracji z użyciem nowej wartości dla BACKEND: django.core.cache.backends.redis.RedisCache. Cały wpis dla przykładowego serwera Redis działającego pod adresem 127.0.0.1 na porcie 6379 będzie prezentował się tak:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379',
    }
}

Zmiany w Django 4.0

Pomniejszych nowości w nowej wersji Django jest znacznie więcej, jednak mają one charakter w dużej mierze utrzymaniowy. Znacznie ważniejsze mogą się jednak okazać zmiany skutkujące potencjalnie utratą wstecznej kompatybilności oraz elementy, które z Django usunięto. 

Framework porzucił wsparcie dla PosgreSQL w wersji niższej niż 10. Wsparcie dla obsługiwanej dotąd wersji 9.6 zakończone zostało w listopadzie. Ponadto nie jest już obsługiwana baza Oracle w wersjach 12.2 i 18c – Django 4.0 obsługuje już domyślnie wyłącznie Oracle 19c. Ponadto z najnowszej wersji frameworka usunięto wszystkie funkcje, które objęte zostały statusem porzuconych w Django 3.0 oraz 3.1. Pełna lista nowości i zmian oraz instrukcje instalacji najnowszej wersji Django zawarte są w dokumentacji.