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.
Poniższe zmiany mogą wymagać aktualizacji Twojego kodu, gdy przejdziesz z wersji 0.95 na 0.96:
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”.
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:
manage.py
do pliku i edytowanie wygenerowanego SQL w celu użycia poprawnych nazw constraintów przed jego wykonaniem.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.manage.py
¶Kilka opcji dla manage.py
zostało zmienionych poprzez dodanie wsparcia dla dodatków:
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.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.).install
została usunięta. Użyj syncdb
.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='\\')
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.
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.
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.
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.
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.
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:
gru 07, 2021