--- title: "Django 1.5 versionsinformation" version: 5.2 locale: sv source: https://docs.djangoproject.com/sv/5.2/releases/1.5/ canonical: https://djangodocs.dev/sv/5.2/releases/1.5/ --- # Django 1.5 versionsinformation *26 februari 2013* Välkommen till Django 1.5! Dessa versionsinformation täcker [nya funktioner](#whats-new-1-5), samt några [bakåtkompatibla ändringar](#backwards-incompatible-1-5) som du bör vara medveten om när du uppgraderar från Django 1.4 eller äldre versioner. Vi har också tagit bort några funktioner, som beskrivs i [vår utfasningsplan](/sv/5.2/internals/deprecation/#deprecation-removed-in-1-5), och vi har [börjat utfasningsprocessen för vissa funktioner](#deprecated-features-1-5). ## Översikt Den största nyheten i Django 1.5 är den [konfigurerbara användarmodellen](#configurable-user-model). Innan Django 1.5 var applikationer som ville använda Djangos auth-ramverk ([`django.contrib.auth`](/sv/5.2/topics/auth/#module-django.contrib.auth)) tvungna att använda Djangos definition av en ”användare”. I Django 1.5 kan du nu byta ut `User`-modellen mot en som du skriver själv. Detta kan vara en enkel förlängning av den befintliga `User`-modellen - till exempel kan du lägga till ett Twitter- eller Facebook-ID-fält - eller så kan du helt ersätta `User` med en helt anpassad för din webbplats. Django 1.5 är också den första utgåvan med [Python 3-stöd](#python-3-support)! Vi kallar detta stöd ”experimentellt” eftersom vi ännu inte anser att det är produktionsfärdigt, men allt är på plats för att du ska kunna börja porta dina appar till Python 3. Vår nästa release, Django 1.6, kommer att stödja Python 3 utan reservationer. Andra anmärkningsvärda nya funktioner i Django 1.5 inkluderar: - [Stöd för att spara en delmängd av modellens fält](#support-for-saving-a-subset-of-model-s-fields) \- [`Model.save()`](/sv/5.2/ref/models/instances/#django.db.models.Model.save) accepterar nu ett `update_fields`-argument, så att du kan ange vilka fält som skrivs tillbaka till databasen när du anropar `save()`. Detta kan vara till hjälp vid operationer med hög samtidighet och kan förbättra prestandan. - Bättre [stöd för strömmande svar](#explicit-streaming-responses) via den nya [`StreamingHttpResponse`](/sv/5.2/ref/request-response/#django.http.StreamingHttpResponse)-svarsklassen. - [GeoDjango](#geodjango) stöder nu PostGIS 2.0. - … och mer; [se nedan](#what-s-new-in-django-1-5). När det är möjligt försöker vi introducera nya funktioner på ett bakåtkompatibelt sätt enligt [vår API-stabilitetspolicy](/sv/5.2/misc/api-stability/). Men som med tidigare utgåvor levereras Django 1.5 med några mindre [bakåtkompatibla ändringar](#backwards-incompatible-1-5); personer som uppgraderar från tidigare versioner av Django bör läsa listan noggrant. En utfasad funktion som är värd att notera är övergången till ”ny stil” [`url`](/sv/5.2/ref/templates/builtins/#std-templatetag-url) tagg. Före Django 1.3 tolkades syntax som `{% url myview %}` felaktigt (Django ansåg att `"myview"` var ett bokstavligt namn på en vy, inte en mallvariabel med namnet `myview`). Django 1.3 och senare introducerade syntaxen `{% load url from future %}` för att införa det korrigerade beteendet där `myview` sågs som en variabel. Slutsatsen av detta är att om du inte använder `{% load url from future %}` i dina mallar, måste du ändra taggar som `{% url myview %}` till `{% url "myview" %}`. Om du *användte* `{% load url from future %}` kan du helt enkelt ta bort den raden under Django 1.5 ## Kompatibilitet med Python Django 1.5 kräver Python 2.6.5 eller högre, men vi rekommenderar **starkt** Python 2.7.3 eller högre. Stöd för Python 2.5 och lägre har tagits bort. Denna förändring bör endast påverka ett litet antal Django-användare, eftersom de flesta leverantörer av operativsystem idag levererar Python 2.6 eller nyare som standardversion. Om du fortfarande använder Python 2.5 måste du dock hålla dig till Django 1.4 tills du kan uppgradera din Python-version. Enligt [vår supportpolicy](/sv/5.2/internals/release-process/) kommer Django 1.4 att fortsätta att få säkerhetsstöd fram till lanseringen av Django 1.6. Django 1.5 körs inte på en Jython final release, eftersom Jythons senaste version för närvarande inte stöder Python 2.6. Jython erbjuder dock för närvarande en alfaversion med 2.7-stöd, och Django 1.5 stöder den alfaversionen. ### Stöd för Python 3 Django 1.5 introducerar stöd för Python 3 - specifikt Python 3.2 och senare. Detta kommer i form av en **enkel** kodbas; du behöver inte installera en annan version av Django på Python 3. Detta innebär att du kan skriva applikationer som är inriktade på bara Python 2, bara Python 3 eller enstaka applikationer som stöder båda plattformarna. Vi kallar dock detta stöd för ”experimentellt” för tillfället: även om det har fått omfattande tester via vår automatiserade testsvit, har det fått mycket lite testning i den verkliga världen. Vi har gjort vårt bästa för att eliminera buggar, men vi kan inte vara säkra på att vi har täckt alla möjliga användningar av Django. Vissa funktioner i Django är inte tillgängliga eftersom de är beroende av programvara från tredje part som inte har portats till Python 3 ännu, inklusive: - mySQL-databasens backend (beror på MySQLdb) - [`ImageField`](/sv/5.2/ref/models/fields/#django.db.models.ImageField) (beror på PIL) - [`LiveServerTestCase`](/sv/5.2/topics/testing/tools/#django.test.LiveServerTestCase) (beror på Selenium WebDriver) Dessutom är Django mer än ett webbramverk; det är ett ekosystem av pluggbara komponenter. Vid denna tidpunkt har mycket få tredjepartsapplikationer portats till Python 3, så det är osannolikt att en verklig applikation kommer att ha alla sina beroenden uppfyllda under Python 3. Därför rekommenderar vi att Django 1.5 inte används i produktion under Python 3. Använd istället detta tillfälle för att börja porta applikationer till Python 3. Om du är författare till en pluggbar komponent uppmuntrar vi dig att börja porta nu. Vi planerar att erbjuda förstklassigt, produktionsfärdigt stöd för Python 3 i vår nästa version, Django 1.6. ## Vad är nytt i Django 1.5 ### Konfigurerbar användarmodell I Django 1.5 kan du nu använda din egen modell som lagringsplats för användarrelaterad data. Om ditt projekt behöver ett användarnamn med mer än 30 tecken, eller om du vill lagra användarnas namn i ett annat format än förnamn/ efternamn, eller om du vill lägga till anpassad profilinformation på ditt User-objekt, kan du nu göra det. Om du har en återanvändbar applikation från tredje part som refererar till User-modellen kan du behöva göra vissa ändringar i hur du refererar till User-instanser. Du bör också dokumentera alla specifika funktioner i User-modellen som din applikation förlitar sig på. Se [dokumentation om anpassade användarmodeller](/sv/5.2/topics/auth/customizing/#auth-custom-user) för mer information. ### Stöd för att spara en delmängd av modellens fält Metoden [`Model.save()`](/sv/5.2/ref/models/instances/#django.db.models.Model.save) har fått ett nytt nyckelordsargument `update_fields`. Genom att använda detta argument är det möjligt att bara spara en utvald lista över modellens fält. Detta kan vara användbart av prestandaskäl eller när man försöker undvika att skriva över samtidiga ändringar. Uppskjutna instanser (de som laddats med `.only()` eller `.defer()`) sparar automatiskt bara de laddade fälten. Om något fält ställs in manuellt efter laddning, kommer det fältet också att uppdateras vid sparandet. Se [`Model.save()`](/sv/5.2/ref/models/instances/#django.db.models.Model.save) dokumentationen för mer information. ### Cachelagring av relaterade modellinstanser Vid traversering av relationer undviker ORM att hämta objekt som tidigare har laddats på nytt. Till exempel med handledningens modeller: ```pycon >>> first_poll = Poll.objects.all()[0] >>> first_choice = first_poll.choice_set.all()[0] >>> first_choice.poll is first_poll True ``` I Django 1.5 utlöser den tredje raden inte längre en ny SQL-fråga för att hämta `first_choice.poll`; den ställdes in av den andra raden. För en-till-en-relationer kan båda sidorna cachelagras. För många-till-en-relationer kan endast den enda sidan av relationen cachelagras. Detta är särskilt användbart i kombination med `prefetch_related`. ### Explicit stöd för strömmande svar Före Django 1.5 var det möjligt att skapa ett strömmande svar genom att skicka en iterator till [`HttpResponse`](/sv/5.2/ref/request-response/#django.http.HttpResponse). Men detta var opålitligt: alla mellanprogram som kom åt attributet [`content`](/sv/5.2/ref/request-response/#django.http.HttpResponse.content) skulle förbruka iteratorn i förtid. Du kan nu uttryckligen generera ett strömmande svar med den nya [`StreamingHttpResponse`](/sv/5.2/ref/request-response/#django.http.StreamingHttpResponse)-klassen. Denna klass exponerar ett [`streaming_content`](/sv/5.2/ref/request-response/#django.http.StreamingHttpResponse.streaming_content)-attribut som är en iterator. Eftersom [`StreamingHttpResponse`](/sv/5.2/ref/request-response/#django.http.StreamingHttpResponse) inte har något `content`-attribut, måste middleware som behöver tillgång till svarsinnehållet testa för strömmande svar och bete sig därefter. ### `{% verbatim %}` mall tagg För att göra det enklare att hantera JavaScript-mallar som kolliderar med Djangos syntax, kan du nu använda [`verbatim`](/sv/5.2/ref/templates/builtins/#std-templatetag-verbatim) block-taggen för att undvika att analysera taggens innehåll. ### Hämtning av `ContentType`-instanser associerade med proxymodeller Metoderna [`ContentTypeManager.get_for_model()`](/sv/5.2/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentTypeManager.get_for_model) och [`ContentTypeManager.get_for_models()`](/sv/5.2/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentTypeManager.get_for_models) har ett nytt nyckelordsargument - respektive `for_concrete_model` och `for_concrete_models`. Genom att skicka `False` med detta argument är det nu möjligt att hämta [`ContentType`](/sv/5.2/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentType) som är associerad med proxymodeller. ### Ny variabel `view` i klassbaserade vykontexter I alla [generiska klassbaserade vyer](/sv/5.2/topics/class-based-views/) (eller alla klassbaserade vyer som ärver från `ContextMixin`) innehåller kontextordboken en `view`-variabel som pekar på `View`-instansen. ### GeoDjango - [`LineString`](/sv/5.2/ref/contrib/gis/geos/#django.contrib.gis.geos.LineString) och [`MultiLineString`](/sv/5.2/ref/contrib/gis/geos/#django.contrib.gis.geos.MultiLineString) GEOS-objekt stöder nu metoderna [`interpolate()`](/sv/5.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSGeometry.interpolate) och [`project()`](/sv/5.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSGeometry.project) (så kallad linjär referens). - Egenskaperna `wkb` och `hex` för [`GEOSGeometry`](/sv/5.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSGeometry)-objekt bevarar Z-dimensionen. - Stöd för PostGIS 2.0 har lagts till och stöd för GDAL \< 1.5 har tagits bort. ### Nya handledningsprogram Bland tilläggen till dokumentationen finns en omarbetad [Tutorial 3](/sv/5.2/intro/tutorial03/) och en ny [tutorial om testning](/sv/5.2/intro/tutorial05/). Ett nytt avsnitt, ”Advanced Tutorials”, erbjuder [Hur man skriver återanvändbara appar](/sv/5.2/intro/reusable-apps/) samt en steg-för-steg-guide för nya bidragsgivare i [Skriv din första patch för Django](/sv/5.2/intro/contributing/). ### Mindre funktioner Django 1.5 innehåller också flera mindre förbättringar som är värda att notera: - Mallmotorn tolkar nu `True`, `False` och `None` som motsvarande Python-objekt. - [`django.utils.timezone`](/sv/5.2/ref/utils/#module-django.utils.timezone) tillhandahåller ett hjälpmedel för att konvertera medvetna datatider mellan tidszoner. Se [`localtime()`](/sv/5.2/ref/utils/#django.utils.timezone.localtime). - De generiska vyerna stöder OPTIONS-begäranden. - Hanteringskommandon ger inte upphov till `SystemExit` längre när de anropas av kod från [`call_command()`](/sv/5.2/ref/django-admin/#django.core.management.call_command). Alla undantag som kommandot ger upphov till (oftast [`CommandError`](/sv/5.2/howto/custom-management-commands/#django.core.management.CommandError)) sprids. Dessutom bör du nu använda `self.stdout.write('message')` och `self.stderr.write('error')` när du skriver ut fel eller meddelanden i dina anpassade kommandon (se anmärkningen om [hanteringskommandon skriver ut](/sv/5.2/howto/custom-management-commands/#management-commands-output)). - Hanteringskommandot [`dumpdata`](/sv/5.2/ref/django-admin/#django-admin-dumpdata) matar ut en rad i taget, vilket förhindrar minnesfel vid dumpning av stora dataset. - I den lokala smaken för Kanada lades `pq` till de acceptabla koderna för Quebec. Det är en gammal förkortning. - Dekoratorn [receiver](/sv/5.2/topics/signals/#connecting-receiver-functions) kan nu ansluta till mer än en signal genom att ange en lista med signaler. - I administratören kan du nu filtrera användare efter grupper som de är medlemmar i. - [`QuerySet.bulk_create()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.bulk_create) har nu ett batch\_size-argument. Som standard är batch\_size obegränsad utom för SQLite där en enda batch är begränsad så att 999 parametrar per fråga inte överskrids. - Inställningarna [`LOGIN_URL`](/sv/5.2/ref/settings/#std-setting-LOGIN_URL) och [`LOGIN_REDIRECT_URL`](/sv/5.2/ref/settings/#std-setting-LOGIN_REDIRECT_URL) accepterar nu även namn på vyfunktioner och [named URL patterns](/sv/5.2/topics/http/urls/#naming-url-patterns). Detta gör att du kan minska antalet konfigurationsdubbleringar. Mer information finns i [`login_required()`](/sv/5.2/topics/auth/default/#django.contrib.auth.decorators.login_required)-dokumentationen. - Django tillhandahåller nu en mod\_wsgi [auth hanterare](/sv/5.2/howto/deployment/wsgi/apache-auth/). - Metoderna [`QuerySet.delete()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.delete) och [`Model.delete()`](/sv/5.2/ref/models/instances/#django.db.models.Model.delete) kan nu använda snabbväg i vissa fall. Den snabba sökvägen möjliggör färre frågor och färre objekt som hämtas till minnet. Se [`QuerySet.delete()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.delete) för mer information. - En instans av `ResolverMatch` lagras på begäran som `resolver_match`. - Som standard skickas alla loggmeddelanden som når loggern `django` när [`DEBUG`](/sv/5.2/ref/settings/#std-setting-DEBUG) är `True` till konsolen (om du inte omdefinierar loggern i din [`LOGGING`](/sv/5.2/ref/settings/#std-setting-LOGGING)-inställning). - Vid användning av [`RequestContext`](/sv/5.2/ref/templates/api/#django.template.RequestContext) är det nu möjligt att söka efter behörigheter genom att använda `{% if 'someapp.someperm' in perms %}` i mallar. - Det är inte längre nödvändigt att ha mallarna `404.html` och `500.html` i rotkatalogen för mallar. Django kommer att mata ut några grundläggande felmeddelanden för båda situationerna när dessa mallar inte hittas. Det är fortfarande rekommenderat som god praxis att tillhandahålla dessa mallar för att presentera vackra felsidor för användaren. - [`django.contrib.auth`](/sv/5.2/topics/auth/#module-django.contrib.auth) tillhandahåller en ny signal som skickas ut när en användare misslyckas med att logga in. Se [`user_login_failed`](/sv/5.2/ref/contrib/auth/#django.contrib.auth.signals.user_login_failed) - Det nya alternativet [`loaddata --ignorenonexistent`](/sv/5.2/ref/django-admin/#cmdoption-loaddata-ignorenonexistent) ignorerar data för fält som inte längre finns. - [`assertXMLEqual()`](/sv/5.2/topics/testing/tools/#django.test.SimpleTestCase.assertXMLEqual) och [`assertXMLNotEqual()`](/sv/5.2/topics/testing/tools/#django.test.SimpleTestCase.assertXMLNotEqual) nya påståenden gör att du kan testa jämlikhet för XML-innehåll på en semantisk nivå, utan att bry dig om syntaxskillnader (mellanslag, attributordning etc.). - RemoteUserMiddleware tvingar nu fram utloggning när REMOTE\_USER-huvudet försvinner under samma webbläsarsession. - Med [cache-baserad sessionsbackend](/sv/5.2/topics/http/sessions/#cached-sessions-backend) kan sessionsdata lagras i en cache som inte är standard. - Index med flera kolumner kan nu skapas på modeller. Läs dokumentationen för `index_together` för mer information. - Under Djangos loggningskonfiguration aktiveras verbose Deprecation-varningar och varningar fångas in i loggningssystemet. Loggade varningar dirigeras genom `console` loggningshanteraren, som som standard kräver att [`DEBUG`](/sv/5.2/ref/settings/#std-setting-DEBUG) är True för att utdata ska genereras. Resultatet är att DeprecationWarnings bör skrivas ut till konsolen i utvecklingsmiljöer på samma sätt som de har gjort i Python-versioner \< 2.7. - API:et för metoden [`django.contrib.admin.ModelAdmin.message_user()`](/sv/5.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.message_user) har ändrats för att acceptera ytterligare argument och lägga till funktioner som liknar [`django.contrib.messages.add_message()`](/sv/5.2/ref/contrib/messages/#django.contrib.messages.add_message). Detta är användbart för att generera felmeddelanden från adminåtgärder. - Administratörens listfilter kan nu anpassas per begäran tack vare den nya metoden [`django.contrib.admin.ModelAdmin.get_list_filter()`](/sv/5.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_list_filter). ## Bakåtkompatibla ändringar i 1.5 > **Warning** > > Utöver de ändringar som beskrivs i det här avsnittet bör du granska [deprecation plan](/sv/5.2/internals/deprecation/#deprecation-removed-in-1-5) för alla funktioner som har tagits bort. Om du inte har uppdaterat din kod inom utfasningstiden för en viss funktion kan borttagningen av den framstå som en bakåtkompatibel ändring. ### `ALLOWED_HOSTS` krävs i produktion Den nya inställningen [`ALLOWED_HOSTS`](/sv/5.2/ref/settings/#std-setting-ALLOWED_HOSTS) validerar begäran `Host` header och skyddar mot host-poisoning attacker. Den här inställningen krävs nu när [`DEBUG`](/sv/5.2/ref/settings/#std-setting-DEBUG) är `False`, annars kommer [`django.http.HttpRequest.get_host()`](/sv/5.2/ref/request-response/#django.http.HttpRequest.get_host) att ge upphov till [`SuspiciousOperation`](/sv/5.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation). För mer information se [`full dokumentation`](/sv/5.2/ref/settings/#std-setting-ALLOWED_HOSTS) för den nya inställningen. ### Chefer på abstrakta modeller Abstrakta modeller kan definiera en egen manager, och den managern :ref:\` kommer att ärvas av alla konkreta modeller som utökar den abstrakta modellen \\`. Men om du försöker använda den abstrakta modellen för att anropa en metod på hanteraren, kommer ett undantag nu att uppstå. Tidigare skulle anropet ha tillåtits, men skulle ha misslyckats så snart som någon databasoperation försökte (vanligtvis med ett ”tabellen finns inte”-fel från databasen). Om du har funktionalitet på en manager som du har anropat med hjälp av den abstrakta klassen, bör du migrera den logiken till en Python `staticmethod` eller `classmethod` på den abstrakta klassen. ### Sammanhang i årsarkivets klassbaserade åsikter För att vara konsekvent med de andra datumbaserade generiska vyerna, skickar [`YearArchiveView`](/sv/5.2/ref/class-based-views/generic-date-based/#django.views.generic.dates.YearArchiveView) nu `year` i sammanhanget som ett [`datetime.date`](https://docs.python.org/3/library/datetime.html#datetime.date) istället för en sträng. Om du använder `{{ year }}` i dina mallar måste du ersätta det med `{{{ year|date:"Y" }}`. `next_year` och `previous_year` har också lagts till i sammanhanget. De beräknas i enlighet med `allow_empty` och `allow_future`. ### Kontext i år och månad arkiv klassbaserade vyer [`YearArchiveView`](/sv/5.2/ref/class-based-views/generic-date-based/#django.views.generic.dates.YearArchiveView) och [`MonthArchiveView`](/sv/5.2/ref/class-based-views/generic-date-based/#django.views.generic.dates.MonthArchiveView) dokumenterades för att tillhandahålla en `date_list` sorterad i stigande ordning i sammanhanget, som deras funktionsbaserade föregångare, men det var faktiskt i fallande ordning. I 1.5 återställdes den dokumenterade ordningen. Du kanske vill lägga till (eller ta bort) nyckelordet `reversed` när du itererar på `date_list` i en mall: ```html+django {% for date in date_list reversed %} ``` [`ArchiveIndexView`](/sv/5.2/ref/class-based-views/generic-date-based/#django.views.generic.dates.ArchiveIndexView) ger fortfarande en `date_list` i fallande ordning. ### Kontext i TemplateView För att vara konsekvent med utformningen av de andra generiska vyerna skickar [`TemplateView`](/sv/5.2/ref/class-based-views/base/#django.views.generic.base.TemplateView) inte längre en `params`-ordbok till kontexten, utan istället variablerna från URLconf direkt till kontexten. ### Icke-formulär data i HTTP-begäranden [`request.POST`](/sv/5.2/ref/request-response/#django.http.HttpRequest.POST) kommer inte längre att inkludera data som postas via HTTP-förfrågningar med icke-formspecifika innehållstyper i rubriken. I tidigare versioner skulle data som postats med andra innehållstyper än `multipart/form-data` eller `application/x-www-form-urlencoded` fortfarande representeras i attributet [`request.POST`](/sv/5.2/ref/request-response/#django.http.HttpRequest.POST). Utvecklare som vill komma åt de råa POST-data för dessa fall bör använda attributet [`request.body`](/sv/5.2/ref/request-response/#django.http.HttpRequest.body) istället. ### [`request_finished`](/sv/5.2/ref/signals/#django.core.signals.request_finished) signal Django brukade skicka signalen [`request_finished`](/sv/5.2/ref/signals/#django.core.signals.request_finished) så snart som view-funktionen returnerade ett svar. Detta samverkade dåligt med [streaming responses](/sv/5.2/ref/request-response/#httpresponse-streaming) som fördröjer generering av innehåll. Denna signal skickas nu efter att innehållet är helt konsumerat av WSGI-gatewayen. Detta kan vara bakåtkompatibelt om du förlitar dig på att signalen avfyras innan du skickar svarsinnehållet till klienten. Om du gör det, bör du överväga att använda [middleware](/sv/5.2/topics/http/middleware/) istället. > **Note** > > Vissa WSGI-servrar och mellanprogram anropar inte alltid `close` på svarsobjektet efter att ha hanterat en begäran, särskilt uWSGI före 1.2.6 och Sentrys mellanprogram för felrapportering upp till 2.0.7. I dessa fall skickas inte signalen `request_finished` alls. Detta kan resultera i inaktiva anslutningar till databas- och memcache-servrar. ### OPTIONS-, PUT- och DELETE-förfrågningar i testklienten Till skillnad från GET och POST implementeras dessa HTTP-metoder inte av webbläsare. Istället används de i API:er som överför data i olika format som JSON eller XML. Eftersom sådana förfrågningar kan innehålla godtyckliga data försöker Django inte avkoda deras kropp. Testklienten använde dock att bygga en frågesträng för OPTIONS och DELETE-förfrågningar som för GET, och en begärandekropp för PUT-förfrågningar som för POST. Denna kodning var godtycklig och inkonsekvent med Djangos beteende när den tar emot förfrågningarna, så den togs bort i Django 1.5. Om du använde parametern `data` i en OPTIONS- eller DELETE-begäran måste du konvertera den till en frågesträng och lägga till den i parametern `path`. Om du använde parametern `data` i en PUT-begäran utan `content_type` måste du koda dina data innan du skickar dem till testklienten och ange argumentet `content_type`. ### Systemversionen av `simplejson` används inte längre [Som förklaras nedan](#simplejson-deprecation), Django 1.5 avskaffar `django.utils.simplejson` till förmån för Python 2.6:s inbyggda [`json`](https://docs.python.org/3/library/json.html#module-json)-modul. I teorin är denna förändring harmlös. Tyvärr, på grund av inkompatibilitet mellan versioner av `simplejson`, kan det utlösa fel under vissa omständigheter. JSON-relaterade funktioner i Django 1.4 använde alltid `django.utils.simplejson`. Denna modul var faktiskt: - En systemversion av `simplejson`, om en sådan fanns tillgänglig (dvs. `import simplejson` fungerar), om den var nyare än Djangos inbyggda kopia eller om den hade C-hastigheterna, eller - Modulen [`json`](https://docs.python.org/3/library/json.html#module-json) från standardbiblioteket, om den var tillgänglig (dvs. Python 2.6 eller senare), eller - En inbyggd kopia av version 2.0.7 av `simplejson`. I Django 1.5 använder dessa funktioner Pythons modul [`json`](https://docs.python.org/3/library/json.html#module-json), som är baserad på version 2.0.9 av `simplejson`. Det finns inga kända inkompatibiliteter mellan Djangos kopia av version 2.0.7 och Pythons kopia av version 2.0.9. Det finns dock vissa inkompatibiliteter mellan andra versioner av `simplejson`: - Medan API:et `simplejson` är dokumenterat som att det alltid returnerar Unicode-strängar, kan den valfria C-implementationen returnera en bytestring. Detta åtgärdades i Python 2.7. - `simplejson.JSONEncoder` fick ett `namedtuple_as_object` nyckelordsargument i version 2.2. Mer information om dessa inkompatibiliteter finns i [ticket #18023](https://code.djangoproject.com/ticket/18023#comment:10). Nettoresultatet är att om du har installerat `simplejson` och din kod använder Djangos serialiseringsinterna direkt - till exempel `django.core.serializers.json.DjangoJSONEncoder`, kan bytet från `simplejson` till `` json` `` bryta din kod. (I allmänhet dokumenteras inte ändringar av interna funktioner; vi gör ett undantag här) Vid denna tidpunkt anser underhållarna av Django att användning av [`json`](https://docs.python.org/3/library/json.html#module-json) från standardbiblioteket ger den starkaste garantin för bakåtkompatibilitet. De rekommenderar att man använder det från och med nu. ### Strängtyper av parametrar för hashermetoder Om du har skrivit en [custom password hasher](/sv/5.2/topics/auth/passwords/#auth-password-storage), bör dina metoder `encode()`, `verify()` eller `safe_summary()` acceptera Unicode-parametrar (`password`, `salt` eller `encoded`). Om någon av hashing-metoderna behöver bytestrings kan du använda [`force_bytes()`](/sv/5.2/ref/utils/#django.utils.encoding.force_bytes) för att koda strängarna. ### Validering av previous\_page\_number och next\_page\_number Vid användning av [object pagination](/sv/5.2/topics/pagination/), kontrollerade inte metoderna `previous_page_number()` och `next_page_number()` i objektet [`Page`](/sv/5.2/ref/paginator/#django.core.paginator.Page) om det returnerade numret låg inom det befintliga sidintervallet. Nu kontrolleras det och ett [`InvalidPage`](/sv/5.2/ref/paginator/#django.core.paginator.InvalidPage)-undantag uppstår när antalet är antingen för lågt eller för högt. ### Beteendet för autocommit-databasalternativet på PostgreSQL ändrades PostgreSQL: s autocommit-alternativ fungerade inte som tidigare annonserat. Det fungerade för enstaka transaktionsblock, men efter att det första blocket hade lämnats återställdes aldrig autocommit-beteendet. Denna bugg är nu fixad i 1.5. Även om detta bara är en buggfix, är det värt att kontrollera dina applikationsbeteenden om du använder PostgreSQL tillsammans med autocommit-alternativet. ### Sessionen sparades inte på 500 svar Djangos session middleware kommer att hoppa över att spara sessionsdata om svarets statuskod är 500. ### E-postkontroll vid misslyckad admininloggning Före Django 1.5, om du försökte logga in i administratörsgränssnittet och av misstag använde din e-postadress istället för ditt användarnamn, skulle administratörsgränssnittet ge en varning som meddelade att din e-postadress inte var ditt användarnamn. I Django 1.5 har införandet av [custom user models](/sv/5.2/topics/auth/customizing/#auth-custom-user) krävt att denna varning tas bort. Detta ändrar inte inloggningsbeteendet på administratörssidan; det påverkar bara varningsmeddelandet som visas under ett visst inloggningsfel. ### Förändringar i testernas utförande Vissa ändringar har införts i utförandet av tester som kan vara bakåtkompatibla för vissa testuppställningar: #### Databasspolning i `django.test.TransactionTestCase` Tidigare trunkerades testdatabasen *före* varje testkörning i en [`TransactionTestCase`](/sv/5.2/topics/testing/tools/#django.test.TransactionTestCase). För att kunna köra enhetstester i vilken ordning som helst och för att se till att de alltid är isolerade från varandra kommer [`TransactionTestCase`](/sv/5.2/topics/testing/tools/#django.test.TransactionTestCase) nu att återställa databasen *efter* varje testkörning istället. #### Ingen mer återställning av implicita DB-sekvenser [`TransactionTestCase`](/sv/5.2/topics/testing/tools/#django.test.TransactionTestCase) tester som används för att återställa primärnyckelsekvenser automatiskt tillsammans med databasspolningsåtgärderna som beskrivs ovan. Detta har ändrats så att inga sekvenser implicit återställs. Detta kan orsaka att [`TransactionTestCase`](/sv/5.2/topics/testing/tools/#django.test.TransactionTestCase)-tester som är beroende av hårdkodade primärnyckelvärden inte fungerar. Det nya attributet [`reset_sequences`](/sv/5.2/topics/testing/advanced/#django.test.TransactionTestCase.reset_sequences) kan användas för att tvinga fram det gamla beteendet för [`TransactionTestCase`](/sv/5.2/topics/testing/tools/#django.test.TransactionTestCase) som kan behöva det. #### Beställning av tester För att säkerställa att all `TestCase`-kod startar med en ren databas, körs testerna nu i följande ordning: - Först körs alla enhetstester (inklusive [`unittest.TestCase`](https://docs.python.org/3/library/unittest.html#unittest.TestCase), [`SimpleTestCase`](/sv/5.2/topics/testing/tools/#django.test.SimpleTestCase), [`TestCase`](/sv/5.2/topics/testing/tools/#django.test.TestCase) och [`TransactionTestCase`](/sv/5.2/topics/testing/tools/#django.test.TransactionTestCase)) utan att någon särskild ordning garanteras eller upprätthålls mellan dem. - Därefter körs alla andra tester (t.ex. doctests) som kan ändra databasen utan att återställa den till dess ursprungliga tillstånd. Detta bör inte orsaka några problem såvida du inte har befintliga doctests som antar att ett [`TransactionTestCase`](/sv/5.2/topics/testing/tools/#django.test.TransactionTestCase) som körts tidigare lämnade något databastillstånd bakom sig eller enhetstester som förlitar sig på att någon form av tillstånd bevaras efter utförandet av andra tester. Sådana tester är redan mycket ömtåliga och måste nu ändras för att kunna köras oberoende. ### `cleaned_data` ordbok sparas för ogiltiga formulär Ordboken [`cleaned_data`](/sv/5.2/ref/forms/api/#django.forms.Form.cleaned_data) är nu alltid närvarande efter validering av formuläret. När formuläret inte valideras innehåller det bara de fält som klarade valideringen. Du bör testa om valideringen lyckades med metoden [`is_valid()`](/sv/5.2/ref/forms/api/#django.forms.Form.is_valid) och inte med närvaron eller frånvaron av attributet [`cleaned_data`](/sv/5.2/ref/forms/api/#django.forms.Form.cleaned_data) på formuläret. ### Beteendet hos `syncdb` med flera databaser `syncdb` frågar nu databasroutrarna för att avgöra om innehållstyper (när `` contenttypes` `` är aktiverat) och behörigheter (när `` auth` `` är aktiverat) ska skapas i måldatabasen. Tidigare skapades de i standarddatabasen, även när en annan databas angavs med alternativet `--database`. Om du använder `syncdb` på flera databaser bör du se till att dina routrar tillåter synkronisering av innehållstyper och behörigheter till endast en av dem. Se dokumenten om [beteende för Contrib-appar med flera databaser](/sv/5.2/topics/db/multi-db/#contrib-app-multiple-databases) för mer information. ### XML-deserializer analyserar inte dokument med en DTD För att förhindra exponering för överbelastningsattacker relaterade till externa entitetsreferenser och entitetsexpansion, vägrar XML-modellens deserializer nu att analysera XML-dokument som innehåller en DTD (DOCTYPE-definition). Eftersom XML-serialisatorn inte matar ut en DTD kommer detta inte att påverka den typiska användningen, utan endast de fall där specialtillverkade XML-dokument skickas till Djangos modelldeserialisator. ### Formulärets standard `max_num` Ett (standard)värde på `None` för argumentet `max_num` i en formulärfabrik tillåter inte längre som standard ett valfritt antal formulär i formuläret. Istället, för att förhindra minnesutmattningsattacker, är standardvärdet nu en gräns på 1000 formulär. Denna gräns kan höjas genom att uttryckligen ange ett högre värde för `max_num`. ### Diverse - [`django.forms.ModelMultipleChoiceField`](/sv/5.2/ref/forms/fields/#django.forms.ModelMultipleChoiceField) returnerar nu en tom `QuerySet` som det tomma värdet istället för en tom lista. - [`int_to_base36()`](/sv/5.2/ref/utils/#django.utils.http.int_to_base36) ger korrekt upphov till ett [`TypeError`](https://docs.python.org/3/library/exceptions.html#TypeError) istället för [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError) för icke-integrala indata. - Mallfiltret `slugify` är nu tillgängligt som en standard Python-funktion på ``django.utils.text.slugify`()``. På samma sätt finns `remove_tags` tillgängligt på `django.utils.html.remove_tags()`. - Uppladdade filer skapas inte längre som körbara som standard. Om du vill att de ska vara körbara ändrar du [`FILE_UPLOAD_PERMISSIONS`](/sv/5.2/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS) efter dina behov. Det nya standardvärdet är `0o666` (oktal) och det aktuella umask-värdet maskeras först. - [`F expressions`](/sv/5.2/ref/models/expressions/#django.db.models.F) stödde bitvisa operatorer med `&` och `|`. Dessa operatorer är nu tillgängliga med hjälp av `.bitand()` och `.bitor()` istället. Borttagandet av `&` och `|` gjordes för att vara konsekvent med [Q()-uttryck](/sv/5.2/topics/db/queries/#complex-lookups-with-q) och `QuerySet` som kombinerar där operatorerna används som booleska AND- och OR-operatorer. - I ett `filter()`-anrop, när [`F uttryck`](/sv/5.2/ref/models/expressions/#django.db.models.F) innehöll uppslagningar som spänner över flervärdiga relationer, återanvände de inte alltid samma relationer som andra uppslagningar längs samma kedja. Detta ändrades, och nu kommer F()-uttryck alltid att använda samma relationer som andra uppslagningar inom samma `filter()`-anrop. - Malltaggen [`csrf_token`](/sv/5.2/ref/templates/builtins/#std-templatetag-csrf_token) är inte längre innesluten i en div. Om du behöver HTML-validering mot DTD:er före HTML5 Strict bör du lägga till en div runt den på dina sidor. - Malltaggbiblioteket `adminmedia`, som endast innehöll den föråldrade malltaggen `{% admin_media_prefix %}`, har tagits bort. Försök att ladda den med `{% load adminmedia %}` kommer att misslyckas. Om dina mallar fortfarande innehåller den här raden måste du ta bort den. - På grund av en implementeringsförseelse var det möjligt att använda [django.contrib.redirects](/sv/5.2/ref/contrib/redirects/) utan att aktivera [django.contrib.sites](/sv/5.2/ref/contrib/sites/). Detta är inte tillåtet längre. Om du använder `django.contrib.redirects`, se till att [`INSTALLED_APPS`](/sv/5.2/ref/settings/#std-setting-INSTALLED_APPS) innehåller `django.contrib.sites`. - ``BoundField.label_tag `()`` escapar nu sitt argument `contents`. För att undvika HTML-escaping, använd [`django.utils.safestring.mark_safe()`](/sv/5.2/ref/utils/#django.utils.safestring.mark_safe) på argumentet innan du skickar det. - Åtkomst till omvända en-till-en-relationer hämtade via [`select_related()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.select_related) ger nu upphov till [`DoesNotExist`](/sv/5.2/ref/models/class/#django.db.models.Model.DoesNotExist) istället för att returnera `None`. ## Funktioner som inte längre är aktuella i 1.5 ### `django.contrib.localflavor` Appen localflavor contrib har delats upp i separata paket. `django.contrib.localflavor` i sig kommer att tas bort i Django 1.6, efter en accelererad avskrivning. De nya paketen finns tillgängliga på GitHub. Kärnteamet kan inte effektivt underhålla dessa paket på lång sikt - det omfattar bara ett dussin länder för närvarande; i likhet med översättningar kommer underhållet att överlämnas till intresserade medlemmar i gemenskapen. ### `django.contrib.markup` Markup Contrib-modulen har utgått och kommer att följa ett påskyndat utrangeringsschema. Direkt användning av Python markup-bibliotek eller taggbibliotek från tredje part föredras framför att Django behåller denna funktionalitet i ramverket. ### `AUTH_PROFILE_MODULE` I och med införandet av [custom user models](/sv/5.2/topics/auth/customizing/#auth-custom-user) finns det inte längre något behov av en inbyggd mekanism för att lagra användarprofildata. Du kan fortfarande definiera användarprofilmodeller som har en en-till-en-relation med User-modellen - i själva verket kommer detta att vara ett lämpligt designmönster att följa för många applikationer som behöver associera data med ett användarkonto. Inställningen `AUTH_PROFILE_MODULE` och metoden `django.contrib.auth.models.User.get_profile()` för åtkomst till användarprofilmodellen bör dock inte användas längre. ### Streamingbeteende för [`HttpResponse`](/sv/5.2/ref/request-response/#django.http.HttpResponse) Django 1.5 avskaffar möjligheten att strömma ett svar genom att skicka en iterator till [`HttpResponse`](/sv/5.2/ref/request-response/#django.http.HttpResponse). Om du förlitar dig på detta beteende, byt till [`StreamingHttpResponse`](/sv/5.2/ref/request-response/#django.http.StreamingHttpResponse). Se [Explicit stöd för strömmande svar](#explicit-streaming-responses) ovan. I Django 1.7 och senare kommer iteratorn att konsumeras omedelbart av [`HttpResponse`](/sv/5.2/ref/request-response/#django.http.HttpResponse). ### `django.utils.simplejson` Eftersom Django 1.5 tappar stödet för Python 2.5 kan vi nu förlita oss på att modulen [`json`](https://docs.python.org/3/library/json.html#module-json) finns tillgänglig i Pythons standardbibliotek, så vi har tagit bort vår egen kopia av `simplejson`. Du bör nu importera [`json`](https://docs.python.org/3/library/json.html#module-json) istället för `django.utils.simplejson`. Tyvärr kan denna ändring ha oönskade sidoeffekter, på grund av inkompatibilitet mellan olika versioner av `simplejson` – se [bakåtkompatibla ändringar](#simplejson-incompatibilities) sektionen. Om du förlitar dig på funktioner som lagts till i `simplejson` efter att det blev Pythons [`json`](https://docs.python.org/3/library/json.html#module-json), bör du importera `simplejson` explicit. ### `django.utils.encoding.StrAndUnicode` Mix-in `django.utils.encoding.StrAndUnicode` har blivit föråldrad. Definiera en `__str__` metod och använd `django.utils.encoding.python_2_unicode_compatible` dekoratorn istället. ### `django.utils.itercompat.product` Funktionen `django.utils.itercompat.product` har blivit föråldrad. Använd den inbyggda [`itertools.product()`](https://docs.python.org/3/library/itertools.html#itertools.product) istället. ### kommando för hantering av `cleanup` Hanteringskommandot `cleanup` har utgått och ersatts av [`clearsessions`](/sv/5.2/ref/django-admin/#django-admin-clearsessions). ### skriptet `daily_cleanup.py` Det odokumenterade skriptet `daily_cleanup.py` har utgått. Använd istället kommandot [`clearsessions`](/sv/5.2/ref/django-admin/#django-admin-clearsessions). ### nyckelordsargumentet `depth` i `select_related` Nyckelordsargumentet `depth` i [`select_related()`](/sv/5.2/ref/models/querysets/#django.db.models.query.QuerySet.select_related) har blivit föråldrat. Du bör använda fältnamn istället.