Duże i ciekawe zmiany w Django 1.7
Od niedawna dostępna jest druga alfa Django 1.7, którą można testować i zgłaszać napotkane błędy. W nowej wersji tego frameworka ujrzymy szereg dużych zmian. Plan przewiduje betę w marcu, a wersję finalną w maju. Co ciekawego znajdziemy w 1.7?
- Django 1.7 wymagać będzie Pythona w wersji nie niższej niż 2.7.
- Dodano migracje zastępujące zewnątrza aplikację South.
- syncdb oznaczono jako przestarzałe. Zastępuje je migrate.
- Dodamo komendę makemigrations do wykrywania zmian i generowania migracji.
- Sygnały pre_syncdb i post_syncdb zmieniono na pre_migrate i post_migrate. Zmianie uległy też argumenty jakie przyjmują.
- Fixtury initial_data nie są automatycznie ładowane dla aplikacji z migracjami. Do ich ładowania zaleca się migracje.
- Zrefaktoryzowano i zmieniono sposób ładowania aplikacji. Wraz z dojrzewaniem idei aplikacji stworzono rejestr aplikacji, w których modele nie odgrywają już głównej roli. Można definiować konfigurację dla poszczególnych aplikacji.
- Aplikacje mogą wykonywać kod na starcie dzięki metodzie ready w ich konfiguracji.
- Etykiety aplikacji ustawiane są poprawnie także do modeli zdefiniowanych poza models.py.
- Można też pomijać plik models.py jeżeli aplikacja nie ma modeli.
- Etykiety aplikacji można zmieniać w konfiguracji, np. by uniknąć konfliktów nazw.
- Panel admina sam wywołuje autodiscover i nie trzeba robić tego ręcznie w URLconf
- Django importuje konfiguracje i modele aplikacji gdy tylko uruchomi się dzięki deterministycznemu procesowi co powinno ułatwić rozwiązywanie problemów z importami (np. zapętlonych importów)
- API pól (klasy Field) wymaga teraz metody deconstruct na potrzeby migracji i kluczy kompozytowych. Dzięki wartościom zwracanym przez tą metodę (name, path, args i kwargs w krotce) można serializować dowolne pole do pliku jak i bezpiecznie je skopiować.
- Dodano metodę as_manager do menedżerów modeli pozwalając tworzyć instancje menedżerów posiadające API QuerySetów, dzięki czemu można korzystać z wielu metod własnych menedżerów. Można też podać menedżer przy iterowaniu po wstecznych relacjach.
- Dodano nowy framework do sprawdzania poprawności kodu (np. poprawności modeli). Framework jest rozszerzalny i pozwala definiować podpowiedzi dla napotykanych problemów. Komenda check zastępuje istniejącą wcześniej komendę validate.
- Dodano obiekt Prefetch pozwalający dopasowywać zachowanie prefetch_related - można podać QuerySet jak i miejsce przechowywania danych. Można też wołać select_related z prefetchowanej relacji.
- Można tworzyć własne wyszukiwania i transformacje dla ORMa Django. Własne wyszukiwania będą zachowywać się jak te już istniejące (np. lte, icontains). Transformacje odpowiadają za zmianę wartości zawartych w bazie danych tuż przed ich wyszukaniem. Można np. napisać transformację, która wyciąga rok z wartości pola - co może umożliwić np. łączenie zapytań. Można po tych wartościach też filtrować.
- Można użyć ModelAdmin.list_display_links = None by wyłączyć linki na liście rekordów (change list) danego modelu w panelu admina.
- Middleware django.contrib.site.middleware.CurrentSiteMiddleware pozwala ustawiać obecną stronę dla każdego żądania.
- Metoda clean formularza nie musi zwracać self.cleaned_data.
- Metoda add_error pozwala dodać błędy do konkretnych pól w formularzu.
- Atrybut errors ma dwie nowe metody - as_data i as_json.
- Wykonanie makemessages w głównym katalogu projektu powinno umieścić frazy w aplikacjach, z których pochodzą.
- Deweloperski runserver będzie używał pyinotify pod Linuksem o ile jest zainstalowane. Dzięki temu serwer będzie reagował szybciej na zmiany i nie będzie co chwila sprawdzał wszystkich plików, co jest znacznie mniej wydajne. Serwer przeładuje się też przy zmianie tłumaczeń (compilemessages).
- Dodano metodę QuerySet.update_or_create().
- Modele mogą być podpinane do sygnałów poprzez łańcuchy typu 'app_label.ModelName'.
Wstecznie niezgodne zmiany
Django 1.7 wprowadza szereg wstecznie niezgodnych zmian związanych głównie z migracjami i zmianą mechanizmu ładowania aplikacji. Wspomniana została już zmiana z initial_data, które nie będą ładowane gdy istnieją migracje.
Zmiana ładowania aplikacji może spowodować wystąpienie wyjątków typu RuntimeError: App registry isn't ready yet.. Rzucane są gdy importując coś z aplikacji wykonujemy kod zależny od rejestru aplikacji (który jeszcze nie istnieje). Może to mieć miejsce gdy robimy zapytania zanim wszystkie modele zostaną załadowane, czy np. przez tłumaczenia robione poprzez ugettext (a nie ugettext_lazy). Wyjątek ImportError: cannot import name pojawi się jeżeli import wpadł w pętlę.
Skrypty wykorzystujące aplikacje Django muszą teraz na początku zainicjalizować framework lub dostaną wspomniany RuntimeError:
import django
django.setup()
Z krótkich testów Django 1.7a2 natrafiłem na problemy z Gunicornem - import nieistniejącego pliku, jak i wyjątek App registry. Większe aplikacje mogą natrafić na błędy w zależnościach i aplikacjach trzecich.
Comment article