---
title: "Django 1.1 versionsinformation"
version: 5.2
locale: sv
source: https://docs.djangoproject.com/sv/5.2/releases/1.1/
canonical: https://djangodocs.dev/sv/5.2/releases/1.1/
---
# Django 1.1 versionsinformation

29 juli 2009

Välkommen till Django 1.1!

Django 1.1 innehåller ett antal snygga [nya funktioner](#whats-new-1-1), 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:

```sql
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:

```sql
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](#test-performance-improvements) 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`](/sv/5.2/topics/testing/tools/#django.test.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](https://github.com/django/django/blob/91f18400cc0fb37659e2dbaab5484ff2081f1f30/django/middleware/http.py#L33).
- 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`](/sv/5.2/ref/models/fields/#django.db.models.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`](/sv/5.2/topics/forms/modelforms/#django.forms.models.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`](/sv/5.2/ref/templates/builtins/#std-templatefilter-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](/sv/5.2/internals/release-process/).

## 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`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet) med resultaten av den aggregerade frågan.

Den här funktionen finns som nya metoder [`aggregate()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.aggregate) och [`annotate()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.annotate) och beskrivs i detalj i [dokumentationen om ORM-aggregering](/sv/5.2/topics/db/aggregation/).

#### 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`](/sv/5.2/ref/models/expressions/#django.db.models.F)-objektet; för fullständig information, inklusive exempel, se [`F expressions documentation`](/sv/5.2/ref/models/expressions/#django.db.models.F).

### 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`](/sv/5.2/ref/models/options/#django.db.models.Options.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`](/sv/5.2/ref/models/options/#django.db.models.Options.managed).

#### Proxy-modeller

Du kan nu skapa [proxymodeller](/sv/5.2/topics/db/models/#proxy-models): 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](/sv/5.2/topics/db/models/#proxy-models). Den här funktionen liknar på ytan ohanterade modeller, så dokumentationen innehåller en förklaring av [hur proxymodeller skiljer sig från ohanterade modeller](/sv/5.2/topics/db/models/#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()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.defer) och [`only()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.only).

### Förbättringar av testning

Några anmärkningsvärda förbättringar har gjorts i [testningsramverket](/sv/5.2/topics/testing/).

#### Förbättringar av testprestanda

Tester som skrivits med Djangos [testing framework](/sv/5.2/topics/testing/) 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`](/sv/5.2/topics/testing/tools/#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`](/sv/5.2/topics/testing/tools/#django.test.TestCase) och [`TransactionTestCase`](/sv/5.2/topics/testing/tools/#django.test.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`](/sv/5.2/topics/testing/tools/#django.test.Client) kan nu automatiskt följa omdirigeringar med argumentet `follow` till [`Client.get()`](/sv/5.2/topics/testing/tools/#django.test.Client.get) och [`Client.post()`](/sv/5.2/topics/testing/tools/#django.test.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](/sv/5.2/ref/contrib/admin/#admin-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](/sv/5.2/topics/conditional-view-processing/) 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](/sv/5.2/topics/http/urls/#naming-url-patterns) 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](/sv/5.2/topics/http/urls/#topics-http-defining-url-namespaces).

### GeoDjango

I Django 1.1 har [GeoDjango](/sv/5.2/ref/contrib/gis/) (dvs. `django.contrib.gis`) flera nya funktioner:

- Stöd för [SpatiaLite](https://www.gaia-gis.it/gaia-sins/) – 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](/sv/5.2/ref/csrf/) 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 [formuläröversikten](/sv/5.2/topics/forms/)) 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 [den fullständiga listan över uppslagstyper](/sv/5.2/ref/models/querysets/#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 [listan över inbyggda malltaggar](/sv/5.2/ref/templates/builtins/) för exempel på detta.
- Hanteringskommandot [`dumpdata`](/sv/5.2/ref/django-admin/#django-admin-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`](/sv/5.2/ref/templates/builtins/#std-templatefilter-safeseq) mallfilter som fungerar precis som [`safe`](/sv/5.2/ref/templates/builtins/#std-templatefilter-safe) för listor och markerar varje objekt i listan som säkert.
- [Cache-backends](/sv/5.2/topics/cache/) 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](/sv/5.2/howto/auth-remote-user/) 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()`](/sv/5.2/topics/http/shortcuts/#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 [native PostgreSQL autocommit](/sv/5.2/ref/databases/#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](/sv/5.2/internals/mailing-lists/#django-developers-mailing-list) 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](/sv/5.2/internals/contributing/)

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.