Django 1.1 release notes

29 juli 2009

Välkommen till Django 1.1!

Django 1.1 innehåller ett antal snygga nya funktioner, massor av buggfixar och en enkel uppgraderingsväg från Django 1.0.

Bakåtkompatibla ändringar i 1.1

Django har en policy om API-stabilitet. Detta innebär att i allmänhet bör kod som du utvecklar mot Django 1.0 fortsätta att fungera mot 1.1 oförändrad. Ibland gör vi dock förändringar som inte är bakåtkompatibla om de är nödvändiga för att lösa buggar, och det finns en handfull sådana (mindre) förändringar mellan Django 1.0 och Django 1.1.

Innan du uppgraderar till Django 1.1 bör du dubbelkolla att följande ändringar inte påverkar dig, och uppgradera din kod om de gör det.

Ändringar av namn på begränsningsåtgärder

Django 1.1 ändrar metoden som används för att generera databasbegränsningsnamn så att namnen är konsekventa oavsett maskinens ordstorlek. Denna ändring är bakåtkompatibel för vissa användare.

Om du använder en 32-bitars plattform är det ingen fara, du kommer inte att märka några skillnader till följd av denna förändring.

Dock kan användare på 64-bitars plattformar uppleva vissa problem vid användning av kommandot reset. Före den här ändringen genererade 64-bitars plattformar ett 64-bitars digest med 16 tecken i begränsningsnamnet, t.ex:

ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...

Efter den här ändringen kommer alla plattformar, oavsett ordstorlek, att generera en 32-bitars digest med 8 tecken i begränsningsnamnet, t.ex:

ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...

Som ett resultat av den här ändringen kommer du inte att kunna använda kommandot reset på en tabell som skapats av en 64-bitars maskin. Detta beror på att det nya genererade namnet inte kommer att matcha det historiskt genererade namnet, vilket leder till att den SQL som skapas med reset-kommandot blir ogiltig.

Om du behöver återställa ett program som skapades med 64-bitarsbegränsningar måste du manuellt ta bort den gamla begränsningen innan du använder reset.

Testfall körs nu i en transaktion

Django 1.1 kör tester inuti en transaktion, vilket ger bättre testprestanda (se förbättringar av testprestanda för detaljer).

Denna ändring är något inkompatibel bakåt om befintliga tester behöver testa transaktionsbeteende, om de bygger på ogiltiga antaganden om testmiljön eller om de kräver en specifik testfallsordning.

För dessa fall kan TransactionTestCase användas istället. Detta är bara en snabb lösning för att komma runt fel i testfall som avslöjas av den nya rollback-metoden; på lång sikt bör tester skrivas om för att korrigera testfallet.

Borttagen SetRemoteAddrFromForwardedFor middleware

För enkelhetens skull inkluderade Django 1.0 en valfri middleware-klass - django.middleware.http.SetRemoteAddrFromForwardedFor - som uppdaterade värdet på REMOTE_ADDR baserat på HTTP X-Forwarded-For header som vanligtvis ställs in av vissa proxy-konfigurationer.

Det har visats att denna mekanism inte kan göras tillräckligt tillförlitlig för allmän användning och att (trots dokumentation om motsatsen) dess inkludering i Django kan leda till att programutvecklare antar att värdet på REMOTE_ADDR är ”säkert” eller på något sätt tillförlitligt som en källa till autentisering.

Även om det inte direkt är en säkerhetsfråga har vi beslutat att ta bort denna mellanvara med Django 1.1-versionen. Det har ersatts med en klass som inte gör något annat än att höja en DeprecationWarning.

Om du har förlitat dig på denna middleware är den enklaste uppgraderingsvägen:

• Undersök koden som den såg ut innan den togs bort.

• Kontrollera att den fungerar korrekt med din upstream-proxy och modifiera den för att stödja just din proxy (om det behövs).

• Presentera din modifierade version av SetRemoteAddrFromForwardedFor som en del av middleware i ditt eget projekt.

Namnen på de uppladdade filerna är tillgängliga senare

I Django 1.0 sparades filer som laddades upp och lagrades i en modells FileField till disk innan modellen sparades till databasen. Detta innebar att det faktiska filnamnet som tilldelats filen var tillgängligt innan det sparades. Det var t.ex. tillgängligt i en modells signalhanterare före sparandet.

I Django 1.1 sparas filen som en del av att spara modellen i databasen, så det faktiska filnamnet som används på disken kan inte åberopas förrän efter att modellen har sparats.

Ändringar av hur modellformulären sparas

I Django 1.1 anropar BaseModelFormSet nu ModelForm.save().

Detta är bakåtkompatibelt om du modifierade self.initial i ett modellformularsets __init__, eller om du förlitade dig på de interna attributen _total_form_count eller _initial_form_count i BaseFormSet. Dessa attribut är nu offentliga metoder.

Fixat join-filtrets escaping-beteende

Filtret join escapear inte längre det bokstavliga värde som skickas in för anslutningen.

Detta är bakåtkompatibelt för den speciella situation där den bokstavliga strängen innehåller ett av de fem HTML-specialtecknen. Om du skrev {{ foo|join:"&" }} måste du alltså nu skriva {{{ foo|join:"&" }}.

Det tidigare beteendet var en bugg och stred mot vad som dokumenterats och förväntades.

Permanenta omdirigeringar och den generiska vyn redirect_to()

Django 1.1 lägger till ett permanent argument till vyn django.views.generic.simple.redirect_to(). Detta är tekniskt bakåtkompatibelt om du använde vyn redirect_to med en formatsträngnyckel som heter ’permanent’, vilket är mycket osannolikt.

Funktioner som inte längre är aktuella i 1.1

En funktion har markerats som utfasad i Django 1.1:

• Du bör inte längre använda AdminSite.root() för att registrera administratörsvyn. Det vill säga, om din URLconf innehåller raden:

  (r"^admin/(.*)", admin.site.root),
  

  Du bör ändra det så att det lyder:

  (r"^admin/", include(admin.site.urls)),
  

Du bör omedelbart börja ta bort användningen av denna funktion från din kod.

AdminSite.root kommer att ge upphov till en PendingDeprecationWarning om den används i Django 1.1. Denna varning är dold som standard. I Django 1.2 kommer denna varning att uppgraderas till en DeprecationWarning, som kommer att visas högt. Django 1.3 kommer att ta bort AdminSite.root() helt och hållet.

För mer information om vår policy och strategi för utfasning, se Djangos lanseringsprocess.

Vad är nytt i Django 1.1

Ganska mycket: sedan Django 1.0 har vi gjort 1 290 kodändringar, åtgärdat 1 206 buggar och lagt till ungefär 10 000 rader dokumentation.

De viktigaste nya funktionerna i Django 1.1 är:

Förbättringar av ORM

Två stora förbättringar har lagts till i Djangos ORM (Object-Relational Mapper): stöd för aggregat och frågeuttryck.

Aggregerat stöd

Det är nu möjligt att köra SQL-aggregatfrågor (dvs. COUNT(), MAX(), MIN(), etc.) från Djangos ORM. Du kan välja att antingen returnera resultaten av aggregatet direkt, eller annotera objekten i en QuerySet med resultaten av den aggregerade frågan.

Den här funktionen finns som nya metoder aggregate() och annotate() och beskrivs i detalj i dokumentationen om ORM-aggregering.

Uttryck för frågor

Frågor kan nu hänvisa till ett annat fält i frågan och kan korsa relationer för att hänvisa till fält i relaterade modeller. Detta är implementerat i det nya F-objektet; för fullständig information, inklusive exempel, se F expressions documentation.

Modellförbättringar

Ett antal funktioner har lagts till i Djangos modellager:

”Ej förvaltade” modeller

Du kan nu kontrollera om Django hanterar livscykeln för databastabellerna för en modell med hjälp av modellalternativet managed. Standardvärdet är True, vilket innebär att Django kommer att skapa lämpliga databastabeller i syncdb och ta bort dem som en del av kommandot reset. Det vill säga, Django hanterar databastabellens livscykel.

Om du anger False kommer dock inga databastabeller att skapas eller tas bort automatiskt för den här modellen. Detta är användbart om modellen representerar en befintlig tabell eller en databasvy som har skapats på något annat sätt.

Mer information finns i dokumentationen för alternativet managed.

Proxy-modeller

Du kan nu skapa proxymodeller: underklasser av befintliga modeller som bara lägger till beteende på Python-nivå (snarare än databasnivå) och som inte representeras av en ny tabell. Det vill säga, den nya modellen är en proxy för någon underliggande modell, som lagrar alla riktiga data.

Alla detaljer finns i dokumentationen för proxymodeller. Den här funktionen liknar på ytan ohanterade modeller, så dokumentationen innehåller en förklaring av :ref:``hur proxymodeller skiljer sig från ohanterade modeller <proxy-vs-unmanaged-models>`.

Uppskjutna fält

I vissa komplexa situationer kan dina modeller innehålla fält som kan innehålla mycket data (t.ex. stora textfält) eller kräva dyr bearbetning för att konvertera dem till Python-objekt. Om du vet att du inte behöver just de här fälten kan du nu säga till Django att inte hämta dem från databasen.

Detta gör du med de nya queryset-metoderna defer() och only().

Förbättringar av testning

Några anmärkningsvärda förbättringar har gjorts i testningsramverket.

Förbättringar av testprestanda

Tester som skrivits med Djangos testing framework körs nu dramatiskt snabbare (så mycket som 10 gånger snabbare i många fall).

Detta åstadkoms genom införandet av transaktionsbaserade tester: när du använder django.test.TestCase, kommer dina tester nu att köras i en transaktion som rullas tillbaka när den är klar, istället för genom att spola och fylla på databasen igen. Detta resulterar i en enorm hastighetshöjning för de flesta typer av enhetstester. Se dokumentationen för TestCase och TransactionTestCase för en fullständig beskrivning och några viktiga anmärkningar om databasstöd.

Testa förbättringar av klienter

Ett par små - men mycket användbara - förbättringar har gjorts i testklienten:

• Testet Client kan nu automatiskt följa omdirigeringar med argumentet follow till Client.get() och Client.post(). Detta gör det enklare att testa vyer som använder omdirigeringar.

• Det är nu lättare att komma åt mallkontexten i svaret som returneras till testklienten: du kommer helt enkelt åt kontexten som request.context[key]. Det gamla sättet, som behandlar request.context som en lista med kontexter, en för varje renderad mall i arvskedjan, är fortfarande tillgängligt om du behöver det.

Nya adminfunktioner

Django 1.1 lägger till ett par smidiga nya funktioner i Djangos admin-gränssnitt:

Redigerbara fält på ändringslistan

Du kan nu göra fält redigerbara på administratörens listvyer via det nya administratörsalternativet list_editable. Dessa fält kommer att visas som formulärwidgets på listsidorna och kan redigeras och sparas i bulk.

Admin ”åtgärder”

Du kan nu definiera adminåtgärder som kan utföra någon åtgärd för en grupp modeller i bulk. Användare kommer att kunna välja objekt på sidan med ändringslistan och sedan tillämpa dessa bulkåtgärder på alla valda objekt.

Django levereras med en fördefinierad adminåtgärd för att ta bort en grupp objekt i ett svep.

Behandling av villkorlig vy

Django har nu mycket bättre stöd för villkorlig vybehandling med hjälp av standard HTTP-rubrikerna ETag och Last-Modified. Detta innebär att du nu enkelt kan kortsluta vybearbetningen genom att testa mindre kostsamma villkor. För många vyer kan detta leda till en allvarlig förbättring av hastigheten och minskning av bandbredden.

Namnrymder för URL

Django 1.1 förbättrar namngivna URL-mönster med införandet av URL-”namnområden”

I korthet innebär den här funktionen att samma grupp av webbadresser, från samma applikation, kan inkluderas i en Django URLConf flera gånger, med varierande (och potentiellt nästlade) namngivna prefix som kommer att användas vid omvänd upplösning. Med andra ord kan återanvändbara applikationer som Djangos admin-gränssnitt registreras flera gånger utan URL-konflikter.

För fullständig information, se dokumentationen om att definiera URL-namnområden.

GeoDjango

I Django 1.1 har GeoDjango (dvs. django.contrib.gis) flera nya funktioner:

• Stöd för SpatiaLite – en spatial databas för SQLite – som en spatial backend.

• Geografiska aggregat (Collect, Extent, MakeLine, Union) och F-uttryck.

• Nya metoder för GeoQuerySet: collect, geojson och snap_to_grid.

• En ny lista med gränssnittsmetoder för GEOSGeometry-objekt.

För mer information, se GeoDjango-dokumentationen.

Övriga förbättringar

Andra nya funktioner och ändringar som införts sedan Django 1.0 inkluderar:

• Den CSRF protection middleware har delats upp i två klasser – CsrfViewMiddleware kontrollerar inkommande förfrågningar och CsrfResponseMiddleware bearbetar utgående svar. Den kombinerade klassen CsrfMiddleware (som gör båda) finns kvar för bakåtkompatibilitet, men att använda de delade klasserna rekommenderas nu för att möjliggöra finkornig kontroll av när och var CSRF-behandlingen äger rum.

• reverse() och kod som använder den (t.ex. malltaggen {% url %}) fungerar nu med webbadresser på Djangos administrativa webbplats, förutsatt att administratörens webbadresser konfigureras via include(admin.site.urls) (att skicka administratörsförfrågningar till vyn admin.site.root fungerar fortfarande, men webbadresser i administratören kommer inte att vara ”reversibla” när de konfigureras på detta sätt).

• Funktionen include() i Django URLconf-moduler kan nu acceptera sekvenser av URL-mönster (genererade av patterns()) utöver modulnamn.

• Instanser av Django formulär (se :doc:formuläröversikten </topics/forms/index>) har nu två ytterligare metoder, hidden_fields() och visible_fields(), som returnerar listan över dolda - dvs <input type="hidden"> - respektive synliga fält i formuläret.

• Den generiska vyn redirect_to accepterar nu ytterligare ett nyckelordsargument permanent. Om permanent är True kommer vyn att avge en permanent HTTP-omdirigering (statuskod 301). Om False, kommer vyn att skicka en HTTP tillfällig omdirigering (statuskod 302).

• En ny databasuppslagstyp - week_day - har lagts till för DateField och DateTimeField. Den här typen av uppslagning accepterar ett tal mellan 1 (söndag) och 7 (lördag) och returnerar objekt där fältvärdet matchar den veckodagen. Se :ref:``den fullständiga listan över uppslagstyper <field-lookups>` för mer information.

• Taggen {% for %} i Djangos mallspråk accepterar nu en valfri klausul {% empty %}, som ska visas när {% for %} ombeds att loopa över en tom sekvens. Se :doc:``listan över inbyggda malltaggar </ref/templates/builtins>` för exempel på detta.

• Hanteringskommandot dumpdata accepterar nu enskilda modellnamn som argument, vilket gör att du kan exportera data bara från vissa modeller.

• Det finns ett nytt safeseq mallfilter som fungerar precis som safe för listor och markerar varje objekt i listan som säkert.

• Cache-backends stöder nu kommandona incr() och decr() för att öka och minska värdet på en cache-nyckel. På cache-backends som stöder atomär ökning/deminskning - framför allt memcached-backend - kommer dessa operationer att vara atomära och ganska snabba.

• Django kan nu enkelt delegera autentisering till webbservern via en ny autentiseringsbackend som stöder standardmiljövariabeln REMOTE_USER som används för detta ändamål.

• Det finns en ny django.shortcuts.redirect()-funktion som gör det enklare att utfärda omdirigeringar givet ett objekt, ett vy-namn eller en URL.

• Backend `` postgresql_psycopg2`` stöder nu :ref:native PostgreSQL autocommit <postgresql-notes>. Detta är en avancerad, PostgreSQL-specifik funktion som kan göra vissa läskrävande applikationer en hel del snabbare.

Vad kommer härnäst?

Vi tar en kort paus, och sedan börjar arbetet med Django 1.2 - ingen vila för de trötta! Om du vill hjälpa till diskuteras Django-utvecklingen, inklusive framsteg mot 1.2-versionen, dagligen på e-postlistan django-developers och i IRC-kanalen #django-dev på irc.libera.chat. Känn dig fri att delta i diskussionerna!

Djangos onlinedokumentation innehåller också tips om hur du kan bidra till Django:

• Hur man bidrar till Django

Bidrag på alla nivåer - att utveckla kod, skriva dokumentation eller bara ta hand om ärenden och hjälpa till att testa föreslagna buggfixar - är alltid välkomna och uppskattade.

Och det är så det är.