Informacje o wydaniu Django w wersji 0.96

Witaj w Django 0.96!

Głównym celem dla 0.96 jest czyszczenie i stabilizacja funkcji wprowadzonych w 0.95. Było kilka małych wstecznie niekompatybilnych zmian od wydania 0.95, ale proces aktualizacji powinien być dosyć prosty i nie powinien wymagać większych zmian w istniejących aplikacjach.

Mimo to, wydajemy teraz wersję 0.96, ponieważ mamy zbiór zmian wstecznie niekompatybilnych, zaplanowanych na najbliższą przyszłość. Gdy będą ukończone, spowodują pewne zmiany w kodzie dla programistów, dlatego zalecamy pozostanie przy Django 0.96 do czasu następnego oficjalnego wydania; Po tym, będziesz mógł zaktualizować wszystko jednorazowo zamiast konieczności dokonywania zmian po kolei, żeby nadążyć za wersją rozwojową Django.

Zmiany niekompatybilne wstecz

Poniższe zmiany mogą wymagać aktualizacji Twojego kodu, gdy przejdziesz z wersji 0.95 na 0.96:

Wymagana wersja MySQLdb

Ze względu na błąd w starszych wersjach modułu Pythona MySQLdb (którego Django używa do łączenia z bazami danych MySQL), backend MySQL Django od teraz wymaga wersji MySQLdb 1.2.1p2 lub wyższej i będzie rzucał wyjątki jeśli spróbujesz użyć starszą wersję.

Jeśli nie jesteś obecnie w stanie zaktualizować swojej kopii MySQLdb, żeby spełnić ten wymóg, dodany został osobny, kompatybilny wstecz backend o nazwie „mysql_old”. Aby użyć tego backendu, zmień ustawienie DATABASE_ENGINE w Twoim pliku ustawień Django z tego:

DATABASE_ENGINE = "mysql"

na to:

DATABASE_ENGINE = "mysql_old"

Mimo tego, mocno namawiamy użytkowników MySQL do zaktualizowania MySQLdb do nowszej wersji tak szybko, jak to możliwe. Backend „mysql_old” istnieje tylko w celu ułatwienia tego przejścia i powinien być uznawany za przestarzały. Oprócz wszystkich niezbędnych poprawek bezpieczeństwa, nie zostanie on aktywnie rozwijany i zostanie usunięty w przyszłych wydaniach Django.

Należy również pamiętać, że niektóre funkcje, takie jak nowe ustawienie DATABASE_OPTIONS (zobacz dokumentację baz danych, aby dowiedzieć się więcej) są dostępne tylko dla backendu „mysql” i nie będą dostępne dla „mysql_old”.

Nazwy constraintów bazy danych uległy zmianie

Format nazw constraintów Django generowanych dla referencji kluczy obcych został lekko zmieniony. Nazwy te są powszechnie stosowane jedynie wówczas, gdy niemożliwe jest umieszczenie referencji bezpośrednio na podlegającej kolumnie, a więc nie zawsze są one widoczne.

The effect of this change is that running manage.py reset and similar commands against an existing database may generate SQL with the new form of constraint name, while the database itself contains constraints named in the old form; this will cause the database server to raise an error message about modifying nonexistent constraints.

Jeśli potrzebujesz to obejść, istnieją dwie metody:

1. Przekierowanie wyjścia manage.py do pliku i edytowanie wygenerowanego SQL w celu użycia poprawnych nazw constraintów przed jego wykonaniem.
2. Zbadać wyjście manage.py sqlall, aby zobaczyć nazwy constraintów stworzonych w nowym stylu i użyć tego jako poradnika do zmiany nazwy obecnych constraintów w Twojej bazie danych.

Zmiany nazw w manage.py

Kilka opcji dla manage.py zostało zmienionych poprzez dodanie wsparcia dla dodatków:

• Nowe komendy dumpdata i loaddata, które działają tak, jak możnaby się tego spodziewać - zrzutują i ładują dane z/do bazy danych. Mogą one działać przeciwko wszelkim wspieranym przez Django formatom serializacji.
• Nazwa komendy sqlinitialdata została zmieniona na sqlcustom, aby podkreślić, że loaddata powinna zostać użyta dla danych (a sqlcustom dla innych, niestandardowych zapytań SQL – widoków, zapisanych procedur itp.).
• Szczątkowa komenda install została usunięta. Użyj syncdb.

Escape’owanie ukośników wstecznych zostało zmienione

The Django database API now escapes backslashes given as query parameters. If you have any database API code that matches backslashes, and it was working before (despite the lack of escaping), you’ll have to change your code to „unescape” the slashes one level.

Na przykład to działało:

# Find text containing a single backslash
MyModel.objects.filter(text__contains="\\\\")

To powyżej jest teraz błędne i powinno zostać przepisane jako:

# Find text containing a single backslash
MyModel.objects.filter(text__contains="\\")

Usunięto ustawienie ENABLE_PSYCO

Ustawienie ENABLE_PSYCO już nie istnieje. Jeśli Twój plik ustawień zawiera ENABLE_PSYCO, nie będzie ono miało żadnego działania. Aby użyć Psyco zalecamy napisanie klasy middleware’u do jego aktywacji.

Co nowego w wersji 0.96?

Ta zmiana składa się z ponad tysiąca commitów kodu źródłowego i ponad czterystu łatek błędów, dlatego niemożliwe jest skatalogowanie wszystkich z dokonanych zmian. Tutaj opisujemy znaczące zmiany w tym wydaniu.

Nowa biblioteka formularzy

django.newforms to nowa biblioteka operowania na formularzach w Django. Stanowi zamiennik dla starego frameworka formularzy, manipulacji i walidacji``django.forms``. Oba API są dostępne w 0.96, ale w ciągu najbliższych dwóch wersji planujemy całkowicie przejść na nowy system formularzy, oznaczyć stary system jako przestarzały i usunąć go.

Są trzy elementy do tego przejścia:

• Skopiowaliśmy aktualne django.forms do django.oldforms. To pozwala Ci na zaktualizowanie swojego kodu teraz zamiast czekania na zmiany niekompatybilne wstecz i pośpiesznie załatać Twój kod po tym fakcie. Po prostu zmień swoje instrukcje importu, jak tutaj:

  from django import forms  # 0.95-style
  from django import oldforms as forms  # 0.96-style
  

• Następne oficjalne wydanie Django przeniesie aktualne django.newforms do django.forms. Będzie to zmiana wstecznie niekompatybilna i każdy, kto nadal używać będzie w tym czasie starej wersji django.forms, będzie musiał zmienić swoje instrukcje importu tak, jak jest to opisane powyżej.

• Następne wydanie po tym całkowicie usunie django.oldforms.

Chociaż nowa biblioteka newforms będzie kontynuować rozwój, jest gotowa do użycia w większości typowych przypadków. Zalecamy, żeby każdy niezaznajomiony z posługiwaniem się formularzami pominął stary system formularzy i zaczął z nowym.

Aby uzyskać więcej informacji na temat django.newforms, przeczytaj dokumentację newforms.

Ulepszenia URLconf

You can now use any callable as the callback in URLconfs (previously, only strings that referred to callables were allowed). This allows a much more natural use of URLconfs. For example, this URLconf:

from django.conf.urls.defaults import *

urlpatterns = patterns("", ("^myview/$", "mysite.myapp.views.myview"))

Może być teraz przepisane jako:

from django.conf.urls.defaults import *
from mysite.myapp.views import myview

urlpatterns = patterns("", ("^myview/$", myview))

One useful application of this can be seen when using decorators; this change allows you to apply decorators to views in your URLconf. Thus, you can make a generic view require login very easily:

from django.conf.urls.defaults import *
from django.contrib.auth.decorators import login_required
from django.views.generic.list_detail import object_list
from mysite.myapp.models import MyModel

info = {
    "queryset": MyModel.objects.all(),
}

urlpatterns = patterns("", ("^myview/$", login_required(object_list), info))

Note that both syntaxes (strings and callables) are valid, and will continue to be valid for the foreseeable future.

Framework testów

Django now includes a test framework so you can start transmuting fear into boredom (with apologies to Kent Beck). You can write tests based on doctest or unittest and test your views with a simple test client.

There is also new support for „fixtures” – initial data, stored in any of the supported serialization formats, that will be loaded into your database at the start of your tests. This makes testing with real data much easier.

See the testing documentation for the full details.

Ulepszenia interfejsu administracyjnego

A small change, but a very nice one: dedicated views for adding and updating users have been added to the admin interface, so you no longer need to worry about working with hashed passwords in the admin.

Podziękowania

Since 0.95, a number of people have stepped forward and taken a major new role in Django’s development. We’d like to thank these people for all their hard work:

• Russell Keith-Magee and Malcolm Tredinnick for their major code contributions. This release wouldn’t have been possible without them.
• Our new release manager, James Bennett, for his work in getting out 0.95.1, 0.96, and (hopefully) future release.
• Our ticket managers Chris Beaven (aka SmileyChris), Simon Greenhill, Michael Radziej, and Gary Wilson. They agreed to take on the monumental task of wrangling our tickets into nicely cataloged submission. Figuring out what to work on is now about a million times easier; thanks again, guys.
• Everyone who submitted a bug report, patch or ticket comment. We can’t possibly thank everyone by name – over 200 developers submitted patches that went into 0.96 – but everyone who’s contributed to Django is listed in AUTHORS.