Django version 0.96 release notes

Välkommen till Django 0.96!

Det primära målet för 0.96 är en upprensning och stabilisering av de funktioner som introducerades i 0.95. Det har skett några små ”bakåtkompatibla ändringar” sedan 0.95, men uppgraderingsprocessen bör vara ganska enkel och inte kräva några större ändringar i befintliga program.

Men vi släpper också 0.96 nu eftersom vi har en uppsättning bakåtkompatibla ändringar planerade för den närmaste framtiden. När de är klara kommer de att innebära vissa kodändringar för applikationsutvecklare, så vi rekommenderar att du håller dig till Django 0.96 fram till nästa officiella release; då kommer du att kunna uppgradera i ett steg istället för att behöva göra stegvisa ändringar för att hålla jämna steg med utvecklingsversionen av Django.

Bakåtkompatibla förändringar

Följande ändringar kan kräva att du uppdaterar din kod när du byter från 0.95 till 0.96:

MySQLdb versionskrav

På grund av en bugg i äldre versioner av Python-modulen MySQLdb (som Django använder för att ansluta till MySQL-databaser) kräver Djangos MySQL-backend nu version 1.2.1p2 eller högre av MySQLdb, och kommer att ge upphov till undantag om du försöker använda en äldre version.

Om du för närvarande inte kan uppgradera din kopia av MySQLdb för att uppfylla detta krav, har en separat, bakåtkompatibel backend, kallad ”mysql_old”, lagts till i Django. För att använda denna backend, ändra inställningen DATABASE_ENGINE i din Django-inställningsfil från detta:

DATABASE_ENGINE = "mysql"

till detta:

DATABASE_ENGINE = "mysql_old"

Vi uppmuntrar dock starkt MySQL-användare att uppgradera till en nyare version av MySQLdb så snart som möjligt, ”mysql_old” backend tillhandahålls endast för att underlätta denna övergång och anses vara föråldrad; bortsett från eventuella nödvändiga säkerhetsfixar kommer den inte att underhållas aktivt och den kommer att tas bort i en framtida version av Django.

Observera också att vissa funktioner, som den nya inställningen DATABASE_OPTIONS (se databasdokumentation för detaljer), endast är tillgängliga på backend ”mysql” och inte kommer att göras tillgängliga för ”mysql_old”.

Namn på databasbegränsningar ändrade

Formatet på de begränsningsnamn som Django genererar för referenser till främmande nycklar har ändrats något. Dessa namn används i allmänhet endast när det inte är möjligt att placera referensen direkt på den berörda kolumnen, så de är inte alltid synliga.

Effekten av denna ändring är att om du kör manage.py reset och liknande kommandon mot en befintlig databas kan SQL genereras med den nya formen av begränsningsnamn, medan databasen i sig innehåller begränsningar med den gamla formen; detta kommer att leda till att databasservern ger ett felmeddelande om att ändra icke-existerande begränsningar.

Om du behöver komma runt detta finns det två metoder tillgängliga:

1. Omdirigera utdata från manage.py till en fil och redigera den genererade SQL-filen så att den använder rätt namn på begränsningarna innan den körs.

2. Granska utdata från manage.py sqlall för att se de nya begränsningsnamnen och använd det som en guide för att byta namn på befintliga begränsningar i din databas.

Namnändringar i manage.py

Några av alternativen i manage.py har ändrats i och med att stöd för fixturer har lagts till:

• Det finns nya kommandon dumpdata och loaddata som, som du kanske förväntar dig, kommer att dumpa och ladda data till / från databasen. Dessa kommandon kan fungera mot något av Djangos stödda serialiseringsformat.

• Kommandot `sqlinitialdata har bytt namn till qlcustom för att betona att loaddata ska användas för data (och qlcustom för annan anpassad SQL - vyer, lagrade procedurer etc.)

• Det rudimentära kommandot install har tagits bort. Använd syncdb.

Backslash escaping ändrad

Djangos databas-API escapar nu backslashes som ges som frågeparametrar. Om du har någon databas-API-kod som matchar bindestreck, och det fungerade tidigare (trots avsaknaden av escaping), måste du ändra din kod för att ”unescape” bindestrecken en nivå.

Till exempel brukade detta fungera:

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

Ovanstående är nu felaktigt och bör skrivas om till:

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

Borttagen inställning ENABLE_PSYCO

Inställningen ENABLE_PSYCO finns inte längre. Om din inställningsfil innehåller ENABLE_PSYCO kommer den inte att ha någon effekt; för att använda Psyco rekommenderar vi att du skriver en middleware-klass för att aktivera den.

Vad är nytt i 0.96?

Denna revision representerar över tusen källkodskommiteringar och över fyrahundra buggfixar, så vi kan omöjligen katalogisera alla ändringar. Här beskriver vi de mest anmärkningsvärda ändringarna i den här versionen.

Nytt formulärbibliotek

django.newforms är Djangos nya bibliotek för formulärhantering. Det är en ersättning för django.forms, det gamla ramverket för formulär/manipulator/validering. Båda API:erna finns tillgängliga i 0.96, men under de kommande två utgåvorna planerar vi att byta helt till det nya formulärsystemet och avskriva och ta bort det gamla systemet.

Denna övergång består av tre delar:

• Vi har kopierat den nuvarande django.forms till django.oldforms. Detta gör att du kan uppgradera din kod nu snarare än att vänta på den bakåtkompatibla ändringen och rusa för att fixa din kod efter det faktum. Ändra bara dina importuttalanden så här:

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

• Nästa officiella version av Django kommer att flytta den nuvarande django.newforms till django.forms. Detta kommer att vara en bakåtkompatibel förändring, och alla som fortfarande använder den gamla versionen av django.forms vid den tiden måste ändra sina importuttalanden enligt beskrivningen ovan.

• Nästa utgåva efter det kommer helt att ta bort django.oldforms.

Även om biblioteket newforms kommer att fortsätta att utvecklas är det klart för användning i de vanligaste fallen. Vi rekommenderar att alla som är nya inom formulärhantering hoppar över det gamla formulärsystemet och börjar med det nya.

För mer information om django.newforms, läs newforms dokumentation.

Förbättringar av URLconf

Du kan nu använda valfri callable som callback i URLconfs (tidigare var endast strängar som refererade till callables tillåtna). Detta möjliggör en mycket mer naturlig användning av URLconfs. Till exempel kan denna URLconf:

from django.conf.urls.defaults import *

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

kan nu skrivas om som:

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

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

En användbar tillämpning av detta kan ses när du använder dekoratorer; denna ändring gör att du kan tillämpa dekoratorer på vyer * i din URLconf *. Således kan du göra en generisk vy som kräver inloggning mycket enkelt:

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))

Observera att båda syntaxerna (strängar och callables) är giltiga och kommer att fortsätta att vara giltiga under överskådlig framtid.

Testramverket

Django innehåller nu ett testramverk så att du kan börja omvandla rädsla till tristess (med ursäkt till Kent Beck). Du kan skriva tester baserade på doctest eller unittest och testa dina vyer med en enkel testklient.

Det finns också nytt stöd för ”fixtures” - initiala data, lagrade i något av de stödda serialiseringsformaten, som laddas in i din databas i början av dina tester. Detta gör det mycket enklare att testa med riktiga data.

Se testdokumentationen för fullständig information.

Förbättringar av administratörsgränssnittet

En liten förändring, men en mycket trevlig sådan: särskilda vyer för att lägga till och uppdatera användare har lagts till i administratörsgränssnittet, så du behöver inte längre oroa dig för att arbeta med hashade lösenord i administratören.

Tack

Sedan 0.95 har ett antal personer klivit fram och tagit en ny stor roll i Djangos utveckling. Vi vill tacka dessa personer för allt deras hårda arbete:

• Russell Keith-Magee och Malcolm Tredinnick för deras viktiga kodbidrag. Den här utgåvan hade inte varit möjlig utan dem.

• Vår nya release manager, James Bennett, för hans arbete med att få ut 0.95.1, 0.96 och (förhoppningsvis) framtida releaser.

• Våra biljettansvariga Chris Beaven (alias SmileyChris), Simon Greenhill, Michael Radziej och Gary Wilson. De gick med på att ta sig an den monumentala uppgiften att samla ihop våra ärenden till en snyggt katalogiserad inlämning. Att räkna ut vad vi ska arbeta med är nu ungefär en miljon gånger enklare; tack igen, killar.

• Alla som har skickat in en buggrapport, patch eller ticket-kommentar. Vi kan omöjligen tacka alla med namn - över 200 utvecklare skickade in patchar som gick in i 0.96 - men alla som har bidragit till Django finns listade i AUTHORS.