Django 1.7 release notes¶

2 september 2014

Välkommen till Django 1.7!

Dessa release notes täcker nya funktioner, samt några bakåtkompatibla ändringar som du bör vara medveten om när du uppgraderar från Django 1.6 eller äldre versioner. Vi har börjat utfasningsprocessen för vissa funktioner, och vissa funktioner har nått slutet av sin utfasningsprocess och har tagits bort.

Kompatibilitet med Python¶

Django 1.7 kräver Python 2.7, 3.2, 3.3 eller 3.4. Vi rekommenderar starkt och stöder endast officiellt den senaste versionen av varje serie.

Django 1.6-serien är den sista som stödjer Python 2.6. Django 1.7 är den första utgåvan som stöder Python 3.4.

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.7 eller nyare som standardversion. Om du fortfarande använder Python 2.6 måste du dock hålla dig till Django 1.6 tills du kan uppgradera din Python-version. Enligt vår supportpolicy kommer Django 1.6 att fortsätta att få säkerhetsstöd fram till lanseringen av Django 1.8.

Vad är nytt i Django 1.7¶

Migrering av scheman¶

Django har nu inbyggt stöd för schemamigreringar. Det gör att modeller kan uppdateras, ändras och raderas genom att skapa migreringsfiler som representerar modelländringarna och som kan köras på vilken utvecklings-, staging- eller produktionsdatabas som helst.

Migreringar behandlas i deras egen dokumentation, men några av de viktigaste funktionerna är:

syncdb har utgått och ersatts av migrate. Oroa dig inte - anrop till syncdb kommer fortfarande att fungera som tidigare.
Det nya kommandot ”Makemigrations” gör det enkelt att automatiskt upptäcka ändringar i dina modeller och göra migreringar för dem.

django.db.models.signals.pre_syncdb och django.db.models.signals.post_syncdb har utgått och ersatts av pre_migrate respektive post_migrate. Dessa nya signaler har något annorlunda argument. Kontrollera dokumentationen för detaljer.
Metoden allow_syncdb på databasroutrar kallas nu allow_migrate, men utför fortfarande samma funktion. Routrar med allow_syncdb-metoder kommer fortfarande att fungera, men det metodnamnet är föråldrat och du bör ändra det så snart som möjligt (inget mer än att byta namn krävs).
initial_data fixturer laddas inte längre för appar med migreringar; om du vill ladda initiala data för en app föreslår vi att du skapar en migrering för din applikation och definierar en RunPython eller RunSQL operation i avsnittet operations i migreringen.
Testets rollback-beteende är annorlunda för appar med migreringar; i synnerhet kommer Django inte längre att emulera rollbacks på icke-transaktionsdatabaser eller inuti TransactionTestCase :ref:``om inte specifikt begärts <test-case-serialized-rollback>`.
Det är inte rekommenderat att låta appar utan migreringar vara beroende av (ha en ForeignKey eller ManyToManyField till) appar med migreringar.

Refaktor för app-laddning¶

Historiskt sett var Django-applikationer tätt kopplade till modeller. En singleton som kallas ”app cache” hanterade både installerade applikationer och modeller. Modulen models användes som en identifierare för applikationer i många API:er.

När konceptet med Django-applikationer mognade visade den här koden vissa brister. Den har omarbetats till ett ”app-register” där modellmoduler inte längre har en central roll och där det är möjligt att bifoga konfigurationsdata till applikationer.

Förbättringarna hittills inkluderar:

Program kan köra kod vid start, innan Django gör något annat, med ready()-metoden i deras konfiguration.
Applikationsetiketter tilldelas korrekt till modeller även när de definieras utanför models.py. Du behöver inte längre ange app_label uttryckligen.
Det är möjligt att helt utelämna models.py om en applikation inte har några modeller.
Applikationer kan märkas om med attributet label i applikationskonfigurationer, för att komma runt etikettkonflikter.
Namnet på applikationer kan anpassas i administratören med verbose_name i applikationskonfigurationer.
Administratören anropar automatiskt autodiscover() när Django startar. Du kan följaktligen ta bort denna rad från din URLconf.
Django importerar alla applikationskonfigurationer och modeller så snart den startar, genom en deterministisk och okomplicerad process. Detta bör göra det lättare att diagnostisera importproblem som t.ex. importloopar.

Ny metod för fältunderklasser¶

För att underlätta både schemamigreringar och för att göra det enklare att lägga till sammansatta nycklar i framtida versioner av Django har API:et Field nu en ny obligatorisk metod: deconstruct().

Denna metod tar inga argument och returnerar en tupel med fyra objekt:

namn: Fältets attributnamn i dess överordnade modell, eller None om det inte är en del av en modell
Sökväg: En prickad Python-sökväg till klassen för detta fält, inklusive klassnamnet.
args: Positionella argument, som en lista
kwargs: Nyckelordets argument, som en dikt

Dessa fyra värden gör att alla fält kan serialiseras till en fil och att fältet kan kopieras på ett säkert sätt, vilket är två viktiga delar av dessa nya funktioner.

Denna ändring bör inte påverka dig om du inte skriver anpassade Field-subklasser; om du gör det kan du behöva omimplementera metoden deconstruct() om din subklass ändrar metodsignaturen för __init__ på något sätt. Om ditt fält bara ärver från ett inbyggt Django-fält och inte åsidosätter __init__, behövs inga ändringar.

Om du behöver åsidosätta deconstruct() är ett bra ställe att börja med de inbyggda Django-fälten (django/db/models/fields/__init__.py) eftersom flera fält, inklusive DecimalField och DateField, åsidosätter det och visar hur man anropar metoden på superklassen och helt enkelt lägger till eller tar bort extra argument.

Detta innebär också att alla argument till fält själva måste vara serialiserbara; för att se vad vi anser vara serialiserbart, och för att ta reda på hur du gör dina egna klasser serialiserbara, läs :ref:``migration serialization documentation <migration-serializing>`.

Anropa anpassade metoder för `QuerySet` från `Manager`¶

Historiskt sett var det rekommenderade sättet att skapa återanvändbara modellfrågor att skapa metoder för en anpassad Manager-klass. Problemet med detta tillvägagångssätt var att efter det första metodanropet fick du tillbaka en QuerySet-instans och kunde inte anropa ytterligare anpassade managermetoder.

Även om det inte finns dokumenterat var det vanligt att man kringgick problemet genom att skapa ett eget QuerySet så att egna metoder kunde kedjas, men lösningen hade ett antal nackdelar:

Den anpassade QuerySet och dess anpassade metoder försvann efter det första anropet till values() eller values_list().
Att skriva en anpassad Manager var fortfarande nödvändigt för att returnera den anpassade QuerySet-klassen och alla metoder som önskades på Manager var tvungna att proxies till QuerySet. Hela processen gick emot DRY-principen.

Klassmetoden QuerySet.as_manager() kan nu direkt skapa Manager med QuerySet-metoder:

class FoodQuerySet(models.QuerySet):
    def pizzas(self):
        return self.filter(kind="pizza")

    def vegetarian(self):
        return self.filter(vegetarian=True)


class Food(models.Model):
    kind = models.CharField(max_length=50)
    vegetarian = models.BooleanField(default=False)
    objects = FoodQuerySet.as_manager()


Food.objects.pizzas().vegetarian()

Använda en anpassad manager vid traversing av omvända relationer¶

Det är nu möjligt att specificera en anpassad chef när man går igenom en omvänd relation:

class Blog(models.Model):
    pass


class Entry(models.Model):
    blog = models.ForeignKey(Blog)

    objects = models.Manager()  # Default Manager
    entries = EntryManager()  # Custom Manager


b = Blog.objects.get(id=1)
b.entry_set(manager="entries").all()

Nytt ramverk för systemkontroll¶

Vi har lagt till en ny Systemkontrollramverk för att upptäcka vanliga problem (som ogiltiga modeller) och ge tips för att lösa dessa problem. Ramverket är utbyggbart så att du kan lägga till dina egna kontroller för dina egna appar och bibliotek.

För att utföra systemkontroller använder du hanteringskommandot check. Detta kommando ersätter det äldre kommandot validate.

Snabbkommandon för administratörer stöder tidszoner¶

Genvägarna ”today” och ”now” bredvid inmatningswidgets för datum och tid i admin fungerar nu i :ref:aktuell tidszon <default-current-time-zone>. Tidigare använde de webbläsarens tidszon, vilket kunde resultera i att fel värde sparades när det inte stämde överens med den aktuella tidszonen på servern.

Dessutom visar widgetarna nu ett hjälpmeddelande när webbläsarens och serverns tidszon skiljer sig åt, för att klargöra hur det värde som anges i fältet ska tolkas.

Använda databasmarkörer som kontexthanterare¶

Före Python 2.7 kunde databasmarkörer användas som kontexthanterare. Den specifika backend-markören definierade beteendet hos kontexthanteraren. Beteendet för magiska metoduppslagningar ändrades med Python 2.7 och markörer var inte längre användbara som kontexthanterare.

Django 1.7 tillåter att en markör används som en kontexthanterare. Det vill säga, följande kan användas:

with connection.cursor() as c:
    c.execute(...)

istället för:

c = connection.cursor()
try:
    c.execute(...)
finally:
    c.close()

Anpassade uppslagningar¶

Det är nu möjligt att skriva egna lookups och transforms för ORM. Anpassade lookups fungerar precis som Djangos inbyggda lookups (t.ex. lte, icontains) medan transforms är ett nytt koncept.

Klassen django.db.models.Lookup ger ett sätt att lägga till uppslagsoperatorer för modellfält. Som ett exempel är det möjligt att lägga till operatorn day_lte för DateFields.

Klassen django.db.models.Transform tillåter transformationer av databasvärden före den slutliga uppslagningen. Det är till exempel möjligt att skriva en year-transform som extraherar år från fältets värde. Transformationer tillåter kedjning. Efter att year-transformationen har lagts till i DateField är det möjligt att filtrera på det transformerade värdet, till exempel qs.filter(author__birthdate__year__lte=1981).

Mer information om både anpassade lookups och transformationer finns i dokumentationen custom lookups.

Förbättringar av felhanteringen för `Form`¶

`Form.add_error()`¶

Tidigare fanns det två huvudmönster för att hantera fel i formulär:

Reser en ValidationError från inom vissa funktioner (t.ex. Field.clean(), Form.clean_<fieldname>(), eller Form.clean() för icke-fältfel.)
Fifflande med Form._errors när man riktar in sig på ett specifikt fält i Form.clean() eller lägger till fel från utanför en ”clean”-metod (t.ex. direkt från en vy).

Att använda det förra mönstret var enkelt eftersom formuläret kan gissa från sammanhanget (dvs. vilken metod som gav upphov till undantaget) var felen hör hemma och automatiskt bearbeta dem. Detta är fortfarande det kanoniska sättet att lägga till fel när det är möjligt. Det senare var dock krångligt och felbenäget, eftersom bördan av att hantera kantfall föll på användaren.

Den nya add_error()-metoden gör det möjligt att lägga till fel i specifika formulärfält var som helst utan att behöva oroa sig för detaljer som att skapa instanser av django.forms.utils.ErrorList eller hantera Form.cleaned_data. Detta nya API ersätter manipulering av Form._errors som nu blir ett privat API.

Se Rengöring och validering av fält som är beroende av varandra för ett exempel där man använder Form.add_error().

Metadata om fel¶

Konstruktören ValidationError accepterar metadata som felets code eller params som sedan är tillgängliga för interpolering i felmeddelandet (se Upphävande av ValidationError för mer information); före Django 1.7 kasserades dock dessa metadata så snart felen lades till i Form.errors.

Form.errors och django.forms.utils.ErrorList lagrar nu ValidationError-instanser så att dessa metadata kan hämtas när som helst via den nya Form.errors.as_data-metoden.

De hämtade ValidationError-instanserna kan sedan identifieras tack vare deras fel code vilket möjliggör saker som att skriva om felmeddelandet eller skriva anpassad logik i en vy när ett visst fel finns. Det kan också användas för att serialisera felen i ett anpassat format, t.ex. XML.

Den nya metoden Form.errors.as_json() är en bekvämlighetsmetod som returnerar felmeddelanden tillsammans med felkoder serialiserade som JSON. as_json() använder as_data() och ger en idé om hur det nya systemet kan utökas.

Felbehållare och bakåtkompatibilitet¶

Stora förändringar av de olika felbehållarna var nödvändiga för att stödja funktionerna ovan, särskilt Form.errors, django.forms.utils.ErrorList och de interna lagren av ValidationError. Dessa behållare som tidigare lagrade felsträngar lagrar nu ValidationError-instanser och offentliga API:er har anpassats för att göra detta så transparent som möjligt, men om du har använt privata API:er är vissa av ändringarna bakåtkompatibla; se ValidationError konstruktör och intern lagring för mer information.

Mindre funktioner¶

`django.contrib.admin`¶

Du kan nu implementera attributen site_header, site_title och index_title på en anpassad AdminSite för att enkelt kunna ändra adminwebbplatsens sidtitel och rubriktext. Inget mer behov av att åsidosätta mallar!
Knappar i django.contrib.admin använder nu CSS-egenskapen border-radius för rundade hörn i stället för GIF-bakgrundsbilder.
Vissa adminmallar har nu klasserna app-<app_name> och model-<model_name> i taggen <body> för att göra det möjligt att anpassa CSS per app eller per modell.
Cellerna i adminändringslistan har nu en field-<field_name>-klass i HTML för att möjliggöra stilanpassningar.
Administratörens sökfält kan nu anpassas per begäran tack vare den nya metoden django.contrib.admin.ModelAdmin.get_search_fields().
Metoden ModelAdmin.get_fields() kan åsidosättas för att anpassa värdet på ModelAdmin.fields.
Förutom den befintliga syntaxen admin.site.register kan du använda den nya register()-dekoratorn för att registrera en ModelAdmin.
Du kan ange ModelAdmin.list_display_links = None för att inaktivera länkar i rutnätet på sidan med ändringslistan.
Du kan nu ange ModelAdmin.view_on_site för att styra om länken ”Visa på webbplatsen” ska visas eller inte.
Du kan ange en fallande ordning för ett ModelAdmin.list_display-värde genom att prefixera admin_order_field-värdet med ett bindestreck.
Metoden ModelAdmin.get_changeform_initial_data() kan åsidosättas för att definiera anpassat beteende för att ställa in initiala ändringsformulärdata.

`django.contrib.auth`¶

Alla **kwargs som skickas till email_user() skickas till det underliggande send_mail()-anropet.
Dekoratorn permission_required() kan ta en lista med behörigheter såväl som en enda behörighet.
Du kan åsidosätta den nya AuthenticationForm.confirm_login_allowed()-metoden för att lättare anpassa inloggningspolicyn.
django.contrib.auth.views.password_reset() tar en valfri html_email_template_name parameter som används för att skicka ett HTML-e-postmeddelande i flera delar för återställning av lösenord.
Metoden AbstractBaseUser.get_session_auth_hash() lades till och om din AUTH_USER_MODEL ärver från AbstractBaseUser, ogiltigförklarar ändring av en användares lösenord nu gamla sessioner om django.contrib.auth.middleware.SessionAuthenticationMiddleware är aktiverat. Se Inaktivering av session vid byte av lösenord för mer information.

`django.contrib.formtools`¶

Anrop till WizardView.done() inkluderar nu en form_dict för att göra det lättare att komma åt formulär genom deras stegnamn.

`django.contrib.gis`¶

Standardversionen av OpenLayers-biblioteket som ingår i widgetar har uppdaterats från 2.11 till 2.13.
Förberedda geometrier stöder nu även predikaten korsningar, disjunkt, överlappningar, touches och inom, om GEOS 3.3 eller senare är installerat.

`django.contrib.messages`¶

Backends för django.contrib.messages som använder cookies, kommer nu att följa inställningarna SESSION_COOKIE_SECURE och SESSION_COOKIE_HTTPONLY.
Kontextprocessorn :ref:messages <message-displaying> lägger nu till en ordlista med standardnivåer under namnet DEFAULT_MESSAGE_LEVELS.
Message-objekt har nu ett level_tag-attribut som innehåller strängrepresentationen av meddelandenivån.

`django.contrib.redirects`¶

RedirectFallbackMiddleware har två nya attribut (response_gone_class och response_redirect_class) som anger vilka typer av HttpResponse-instanser som middlewaren returnerar.

`django.contrib.sessions`¶

Sessionsbackend "django.contrib.sessions.backends.cached_db" respekterar nu SESSION_CACHE_ALIAS. I tidigare versioner använde den alltid standard-cachen.

`django.contrib.sitemaps`¶

Ramverket sitemap<django.contrib.sitemaps>` använder nu lastmod` för att ställa in en Last-Modified header i svaret. Detta gör det möjligt för ConditionalGetMiddleware att hantera villkorliga GET-begäranden för sitemaps som anger lastmod.

`django.contrib.sites`¶

Den nya django.contrib.sites.middleware.CurrentSiteMiddleware gör det möjligt att ställa in den aktuella webbplatsen vid varje förfrågan.

`django.contrib.staticfiles`¶

Klassen static files storage classes kan underklassas för att åsidosätta de behörigheter som insamlade statiska filer och kataloger får genom att ange parametrarna file_permissions_mode och directory_permissions_mode. Se collectstatic för exempel på användning.
Backend CachedStaticFilesStorage får en syskonklass som heter ManifestStaticFilesStorage` som inte använder cachesystemet alls utan istället en JSON-fil som heter staticfiles.json för att lagra mappningen mellan det ursprungliga filnamnet (t.ex. css/styles.css) och det hashade filnamnet (t.ex. css/styles.55e7cbb9ba48.css). Filen staticfiles.json skapas när man kör hanteringskommandot collectstatic och bör vara ett billigare alternativ för fjärrlagring som Amazon S3.

Se ManifestStaticFilesStorage-dokumenten för mer information.
findstatic accepterar nu verbosity flaggnivå 2, vilket innebär att den kommer att visa de relativa sökvägarna till de kataloger den sökte i. Se findstatic för exempel på utdata.

`django.contrib.syndication`¶

Syndikeringsflödets updated-element i Atom1Feed använder nu updateddate istället för pubdate, vilket gör att published-elementet kan inkluderas i flödet (som förlitar sig på pubdate).

Cache¶

Åtkomst till cacher som konfigurerats i CACHES är nu tillgänglig via django.core.cache.caches. Detta diktliknande objekt tillhandahåller en annan instans per tråd. Det ersätter django.core.cache.get_cache() som nu är föråldrat.
Om du instansierar cache backends direkt, var medveten om att de inte är tråd-säkra längre, eftersom django.core.cache.caches nu ger olika instanser per tråd.
Om argumentet TIMEOUT i inställningen CACHES anges som None kommer cache-nycklarna att anges som ”non-expiring” som standard. Tidigare var det bara möjligt att skicka timeout=None till cachebackendets set()-metod.

Cross Site Request Forgery¶

Inställningen CSRF_COOKIE_AGE underlättar användningen av sessionsbaserade CSRF-cookies.

E-postadress¶

send_mail() accepterar nu en html_message parameter för att skicka ett flerdelat text/plain och text/html e-postmeddelande.
SMTP :klassen:`~django.core.mail.backends.smtp.EmailBackend` accepterar nu en timeout parameter.

Fil delning¶

Fillåsning i Windows var tidigare beroende av paketet PyWin32; om det inte var installerat misslyckades fillåsningen i tysthet. Det beroendet har tagits bort och fillåsning implementeras nu inbyggt i både Windows och Unix.

Filuppladdning¶

Det nya attributet UploadedFile.content_type_extra innehåller extra parametrar som skickas till rubriken content-type på en filuppladdning.
Den nya inställningen FILE_UPLOAD_DIRECTORY_PERMISSIONS styr filsystembehörigheterna för kataloger som skapas under filuppladdning, på samma sätt som FILE_UPLOAD_PERMISSIONS gör för själva filerna.
Attributet FileField.upload_to är nu valfritt. Om det utelämnas eller ges None eller en tom sträng, kommer en underkatalog inte att användas för att lagra de uppladdade filerna.
Uppladdade filer stängs nu uttryckligen innan svaret levereras till klienten. Delvis uppladdade filer stängs också så länge de har namnet file i uppladdningshanteraren.
Storage.get_available_name() lägger nu till ett understreck plus en slumpmässig alfanumerisk sträng med 7 tecken (t.ex. "_x3a1gho"), snarare än att iterera genom ett understreck följt av ett nummer (t.ex. "_1", "_2", etc.) för att förhindra en överbelastningsattack. Den här ändringen gjordes även i säkerhetsversionerna 1.6.6, 1.5.9 och 1.4.14.

Formulär¶

Taggarna <label> och <input> som återges av RadioSelect och CheckboxSelectMultiple när de loopar över radioknapparna eller kryssrutorna innehåller nu attributen for respektive id. Varje radioknapp eller kryssruta innehåller ett id_for_label-attribut för att mata ut elementets ID.
Taggarna <textarea> som återges av Textarea innehåller nu ett attribut maxlength om modellfältet TextField har en max_length.
Field.choices låter dig nu anpassa etiketten för ”tomt val” genom att inkludera en tupel med en tom sträng eller None för nyckeln och den anpassade etiketten som värde. Standardalternativet "----------" kommer att utelämnas i detta fall.
MultiValueField tillåter valfria underfält genom att sätta argumentet require_all_fields till False. Attributet required för varje enskilt fält kommer att respekteras, och ett nytt valideringsfel incomplete kommer att uppstå när något av de obligatoriska fälten är tomt.
Metoden clean() på ett formulär behöver inte längre returnera self.cleaned_data. Om den returnerar en ändrad ordbok kommer den fortfarande att användas.
Efter en tillfällig regression i Django 1.6 är det nu möjligt igen att få TypedChoiceField coerce-metoden att returnera ett godtyckligt värde.
SelectDateWidget.months kan användas för att anpassa ordalydelsen för de månader som visas i Select Widget.
Parametrarna min_num och validate_min lades till i formset_factory() för att möjliggöra validering av ett minsta antal inskickade formulär.
De metaklasser som används av Form och ModelForm har omarbetats för att stödja fler arvsscenarier. Den tidigare begränsningen som förhindrade att man ärvde från både Form och ModelForm samtidigt har tagits bort så länge som ModelForm visas först i MRO.
Det är nu möjligt att ta bort ett fält från en Form vid subklassning genom att ställa in namnet till None.
Det är nu möjligt att anpassa felmeddelandena för ModelForm begränsningarna unique, unique_for_date och unique_together. För att stödja unique_together eller någon annan NON_FIELD_ERROR, letar ModelForm nu efter NON_FIELD_ERROR nyckeln i error_messages dictionariet i ModelForm inre Meta klass. Se :ref:överväganden angående modellens error_messages <considerations-regarding-model-errormessages> för mer information.

Internationalisering¶

Med attributet django.middleware.locale.LocaleMiddleware.response_redirect_class kan du anpassa de omdirigeringar som utfärdas av mellanvaran.
Klassen:~django.middleware.locale.LocaleMiddleware lagrar nu användarens valda språk med sessionsnyckeln _language. Detta bör endast nås med hjälp av konstanten LANGUAGE_SESSION_KEY. Tidigare lagrades det med nyckeln django_language och konstanten LANGUAGE_SESSION_KEY fanns inte, men nycklar som är reserverade för Django bör börja med ett understreck. För bakåtkompatibilitet läses django_language fortfarande från i 1.7. Sessioner kommer att migreras till den nya nyckeln när de skrivs.
Taggen blocktrans har nu stöd för alternativet trimmed. Detta alternativ kommer att ta bort tecken för nya rader från början och slutet av innehållet i taggen {% blocktrans %}, ersätta alla blanksteg i början och slutet av en rad och slå samman alla rader till en med ett mellanslagstecken för att separera dem. Detta är mycket användbart för att indentera innehållet i en {% blocktrans %} tagg utan att indentationstecknen hamnar i motsvarande post i filen .po, vilket gör översättningsprocessen enklare.
När du kör makemessages från rotkatalogen i ditt projekt, kommer alla extraherade strängar nu automatiskt att distribueras till rätt app eller projektmeddelandefil. Se Lokalisering: hur man skapar språkfiler för mer information.
Kommandot makemessages lägger nu alltid till kommandoradsflaggan --previous till kommandot msgmerge, vilket gör att tidigare översatta strängar i .po-filer behålls för luddiga strängar.
Följande inställningar för att justera språkcookiealternativen introducerades: LANGUAGE_COOKIE_AGE, LANGUAGE_COOKIE_DOMAIN och LANGUAGE_COOKIE_PATH.
Lagt till Lokalisering av format för Esperanto.

Kommandon för hantering¶

Det nya --no-color-alternativet för django-admin inaktiverar färgläggning av kommandoutmatningen för hantering.
De nya alternativen dumpdata --natural-foreign och dumpdata --natural-primary samt de nya argumenten use_natural_foreign_keys och use_natural_primary_keys för serializers.serialize() gör det möjligt att använda naturliga primärnycklar vid serialisering.
Det är inte längre nödvändigt att ange namnet på cachetabellen eller alternativet --databas för kommandot createcachetable. Django hämtar denna information från din inställningsfil. Om du har konfigurerat flera cacheminnen eller flera databaser skapas alla cachetabeller.
Kommandot runserver har fått flera förbättringar:
- På Linux-system, om pyinotify är installerat, laddas utvecklingsservern om omedelbart när en fil ändras. Tidigare pollade den filsystemet efter ändringar varje sekund. Det orsakade en liten fördröjning innan omladdningar och minskade batteritiden på bärbara datorer.
- Dessutom laddas utvecklingsservern automatiskt om när en översättningsfil uppdateras, dvs. efter körning av compilemessages.
- Alla HTTP-förfrågningar loggas till konsolen, inklusive förfrågningar om statiska filer eller favicon.ico som tidigare filtrerades bort.
Hanteringskommandon kan nu producera syntaxfärgad utdata under Windows om ANSICON tredjepartsverktyg är installerat och aktivt.
collectstatic-kommandot med symlink-alternativet stöds nu på Windows NT 6 (Windows Vista och senare).
Initiala SQL-data fungerar nu bättre om Python-biblioteket sqlparse är installerat.

Observera att det är föråldrat till förmån för RunSQL operation av migreringar, som drar nytta av det förbättrade beteendet.

Modeller¶

Metoden QuerySet.update_or_create() lades till.
Det nya alternativet default_permissions model Meta gör att du kan anpassa (eller inaktivera) skapandet av standardbehörigheterna för att lägga till, ändra och ta bort.
Explicit OneToOneField för Arv från flera tabeller upptäcks nu i abstrakta klasser.
Det är nu möjligt att undvika att skapa en bakåtriktad relation för OneToOneField genom att ställa in dess related_name till '+' eller avsluta den med '+'.
F uttryck stödjer potensoperatorn (**).
Metoderna remove() och clear() för de relaterade hanterarna som skapats av ForeignKey och GenericForeignKey accepterar nu nyckelordsargumentet bulk för att styra om operationer ska utföras i bulk eller inte (dvs. med hjälp av QuerySet.update()). Standardvärdet är True.
Det är nu möjligt att använda None som ett frågevärde för iexact lookup.
Det är nu möjligt att skicka en callable som värde för attributet limit_choices_to när man definierar en ForeignKey eller ManyToManyField.
Anrop av only() och defer() på resultatet av QuerySet.values() ger nu upphov till ett fel (tidigare skulle det antingen resultera i ett databasfel eller felaktiga data).
Du kan använda en enda lista för index_together (i stället för en lista med listor) när du anger en enda uppsättning fält.
Anpassade mellanliggande modeller som har mer än en främmande nyckel till någon av de modeller som deltar i en många-till-många-relation är nu tillåtna, förutsatt att du uttryckligen anger vilka främmande nycklar som ska användas genom att ange det nya ManyToManyField.through_fields-argumentet.
Att tilldela en modellinstans till ett fält som inte är ett relationsfält ger nu upphov till ett fel. Tidigare fungerade detta om fältet accepterade heltal som indata eftersom det tog primärnyckeln.
Heltalsfält valideras nu mot databasens backend-specifika min- och maxvärden baserat på deras internal_type. Tidigare förhindrade inte validering av modellfält att värden utanför deras associerade kolumndatatypintervall sparades, vilket resulterade i ett integritetsfel.
Det är nu möjligt att explicit order_by() ett relationsfält _id genom att använda dess attributnamn.

Signaler¶

Argumentet enter lades till i signalen setting_changed.
Modellsignalerna kan nu kopplas till med hjälp av en str i formuläret 'app_label.ModelName - precis som relaterade fält - för att enkelt referera till deras avsändare.

Mallar¶

Metoden Context.push() returnerar nu en kontexthanterare som automatiskt anropar pop() när with-satsen avslutas. Dessutom accepterar push() nu parametrar som skickas till konstruktören dict som används för att bygga den nya kontextnivån.
Den nya Context.flatten()-metoden returnerar en Context-stack som en platt ordbok.
Context-objekt kan nu jämföras för jämlikhet (internt använder detta Context.flatten() så den interna strukturen i varje Context-stack spelar ingen roll så länge deras utplattade version är identisk).
Malltaggen widthratio accepterar nu en "as"-parameter för att fånga resultatet i en variabel.
Malltaggen include kommer nu också att acceptera allt med en render()-metod (t.ex. en Template) som ett argument. Strängargument kommer att sökas upp med get_template() som alltid.
Det är nu möjligt att include mallar rekursivt.
Mallobjekt har nu ett ursprungsattribut inställt när TEMPLATE_DEBUG är True. Detta gör att mallens ursprung kan inspekteras och loggas utanför infrastrukturen django.template.
TypeError-undantag tystas inte längre när de uppstår under rendering av en mall.
Följande funktioner accepterar nu en dirs parameter som är en lista eller tupel för att åsidosätta TEMPLATE_DIRS:
- django.template.loader.get_template()
- django.template.loader.select_template()
- django.shortcuts.render()
- django.shortcuts.render_to_response()
Filtret time accepterar nu tidszonsrelaterade formatspecifikationer 'e', 'O' , 'T' och 'Z' och kan smälta :ref:tidszonsmedvetna <naive_vs_aware_datetimes>` ``datetime-instanser som utför den förväntade renderingen.
Taggen cache kommer nu att försöka använda cachen som heter ”template_fragments” om den finns och annars återgå till att använda standardcachen. Den accepterar nu också ett valfritt using nyckelordsargument för att kontrollera vilken cache den använder.
Det nya filtret truncatechars_html trunkerar en sträng så att den inte är längre än det angivna antalet tecken, med hänsyn tagen till HTML.

Förfrågningar och svar¶

Det nya attributet HttpRequest.scheme anger schemat för begäran (normalt http eller https).
Genvägen redirect() stöder nu relativa webbadresser.
Den nya underklassen JsonResponse av HttpResponse hjälper till att enkelt skapa JSON-kodade svar.

Tester¶

DiscoverRunner har två nya attribut, test_suite och test_runner, som gör det möjligt att åsidosätta hur tester samlas in och körs.
Argumentet fetch_redirect_response lades till i assertRedirects(). Eftersom testklienten inte kan hämta externa webbadresser gör detta att du kan använda assertRedirects med omdirigeringar som inte är en del av din Django-app.
Korrekt hantering av schema när jämförelser görs i assertRedirects().
Argumentet secure har lagts till i alla förfrågningsmetoder i Client. Om True, kommer begäran att göras via HTTPS.
assertNumQueries() skriver nu ut listan över exekverade frågor om påståendet misslyckas.
Instansen WSGIRequest som genereras av testhanteraren är nu kopplad till attributet django.test.Response.wsgi_request.
Databasinställningarna för testning har samlats i en ordbok med namnet TEST.

Verktyg¶

Förbättrad strip_tags() noggrannhet (men den kan fortfarande inte garantera ett HTML-säkert resultat, som anges i dokumentationen).

Validerare¶

RegexValidator accepterar nu de valfria argumenten flags och Boolean inverse_match. Attributet inverse_match avgör om ValidationError ska tas upp när det reguljära uttrycksmönstret matchar (True) eller inte matchar (False, som standard) det angivna värdet. Attributet flags anger de flaggor som används när en sträng med reguljära uttryck sammanställs.
URLValidator accepterar nu ett valfritt schemes-argument som gör det möjligt att anpassa de accepterade URI-schemana (istället för standardvärdena http(s) och ftp(s)).
validate_email() accepterar nu adresser med IPv6-litteraler, som example@[2001:db8::1], enligt RFC 5321.

Bakåtkompatibla ändringar i 1.7¶

Varning

Utöver de ändringar som beskrivs i det här avsnittet bör du granska deprecation plan 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.

`allow_syncdb` / `allow_migrate`¶

Medan Django fortfarande kommer att titta på allow_syncdb-metoder även om de bör bytas ut till allow_migrate, finns det en subtil skillnad i vilka modeller som skickas till dessa metoder.

För appar med migreringar kommer allow_migrate nu att godkännas :ref:historical models <historical-models>, som är speciella versionerade modeller utan anpassade attribut, metoder eller chefer. Se till att dina allow_migrate-metoder endast hänvisar till fält eller andra objekt i model._meta.

initial_data¶

Appar med migreringar laddar inte initial_data-fixturer när de har slutfört migreringen. Appar utan migreringar kommer att fortsätta att ladda dessa fixturer under fasen migrate som emulerar det gamla syncdb-beteendet, men alla nya appar kommer inte att ha detta stöd.

Istället uppmuntras du att ladda initiala data i migreringar om du behöver det (med hjälp av RunPython-operationen och dina modellklasser); detta har den extra fördelen att dina initiala data inte behöver uppdateras varje gång du ändrar schemat.

Dessutom har initial_data, precis som resten av Djangos gamla syncdb-kod, börjat avskrivas och kommer att tas bort i Django 1.9.

`deconstruct() och serialiserbarhet¶

Django kräver nu att alla Field-klasser och alla deras konstruktörsargument är serialiserbara. Om du ändrar konstruktörsignaturen i ditt anpassade fält på något sätt måste du implementera en deconstruct()-metod; vi har utökat dokumentationen för anpassade fält med :ref:``instruktioner om hur du implementerar den här metoden <custom-field-deconstruct-method>`.

Kravet på att alla fältargument ska vara serialiserbara innebär att alla anpassade klassinstanser som skickas till fältkonstruktörer - saker som anpassade Storage-subklasser, till exempel - måste ha en deconstruct-metod definierad på dem också, men Django tillhandahåller en praktisk klassdekorator som fungerar för de flesta applikationer.

Ändringar i app-laddning¶

Uppstartssekvens¶

Django 1.7 laddar applikationskonfigurationer och modeller så snart den startar. Även om detta beteende är mer okomplicerat och tros vara mer robust, kan regressioner inte uteslutas. Se Felsökning för lösningar på vissa problem som du kan stöta på.

Fristående skript¶

Om du använder Django i ett vanligt Python-skript - snarare än ett managementkommando - och du förlitar dig på miljövariabeln DJANGO_SETTINGS_MODULE, måste du nu uttryckligen initiera Django i början av ditt skript med:

>>> import django
>>> django.setup()

Annars kommer du att få ett AppRegistryNotReady undantag.

WSGI-skript¶

Fram till Django 1.3 var det rekommenderade sättet att skapa en WSGI-applikation:

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

I Django 1.4 förbättrades stödet för WSGI och API:et ändrades till:

from django.core.wsgi import get_wsgi_application

application = get_wsgi_application()

Om du fortfarande använder den förra stilen i ditt WSGI-skript måste du uppgradera till den senare, annars kommer du att få ett AppRegistryNotReady-undantag.

Konsistens i appregistret¶

Det är inte längre möjligt att ha flera installerade applikationer med samma etikett. I tidigare versioner av Django fungerade detta inte alltid korrekt, men det kraschade inte heller direkt.

Om du har två appar med samma etikett bör du skapa en AppConfig för en av dem och åsidosätta dess label där. Du bör sedan justera din kod överallt där den refererar till denna applikation eller dess modeller med den gamla etiketten.

Det är inte längre möjligt att importera samma modell två gånger via olika sökvägar. Från och med Django 1.6 kan detta endast hända om du manuellt lägger till en katalog och en underkatalog på PYTHONPATH. Se avsnittet om den nya projektlayouten i 1.4 release notes för migreringsinstruktioner.

Det bör du se till att göra:

Alla modeller definieras i applikationer som är listade i INSTALLED_APPS eller har en explicit app_label.
Modeller importeras inte som en bieffekt av att deras applikation laddas. Specifikt bör du inte importera modeller i rotmodulen för en applikation eller i den modul som definierar dess konfigurationsklass.

Django kommer att tillämpa dessa krav från och med version 1.9, efter en utfasningsperiod.

Underklassificering av AppCommand¶

Subklasser av AppCommand måste nu implementera en handle_app_config()-metod istället för handle_app(). Denna metod tar emot en AppConfig-instans istället för en models-modul.

Introspekterande tillämpningar¶

Eftersom INSTALLED_APPS nu stöder programkonfigurationsklasser utöver programmoduler, bör du se över kod som har direkt åtkomst till denna inställning och använda appregistret (django.apps.apps) istället.

Appregistret har bevarat vissa funktioner från den gamla appcachen. Även om appcachen var ett privat API kommer föråldrade metoder och argument att tas bort genom en standardväg för föråldring, med undantag för följande ändringar som träder i kraft omedelbart:

get_model ger upphov till LookupError istället för att returnera None när ingen modell hittas.
Argumentet only_installed i get_model och get_models finns inte längre, inte heller argumentet seed_cache i get_model.

Hanteringskommandon och ordning för `INSTALLED_APPS`¶

När flera applikationer tillhandahåller hanteringskommandon med samma namn, laddar Django kommandot från den applikation som kommer först i INSTALLED_APPS. Tidigare versioner laddade kommandot från den applikation som kom sist.

Detta gör att upptäckten av hanteringskommandon är i linje med andra delar av Django som förlitar sig på ordningen för INSTALLED_APPS, till exempel statiska filer, mallar och översättningar.

`ValidationError` konstruktör och intern lagring¶

Beteendet för konstruktören ValidationError har ändrats när den tar emot en behållare med fel som argument (t.ex. en list eller en ErrorList):

Den konverterar alla strängar den hittar till instanser av ValidationError innan den lägger till dem i sitt interna lager.
Den lagrar inte den givna behållaren utan kopierar dess innehåll till sin egen interna lagring; tidigare lades själva behållaren till i ValidationError-instansen och användes som intern lagring.

Detta innebär att om du kommer åt ValidationError interna lagringsplatser, såsom error_list; error_dict; eller returvärdet av update_error_dict() kan du hitta instanser av ValidationError där du tidigare skulle ha hittat strängar.

Även om du direkt tilldelade returvärdet av update_error_dict() till Form._errors kan du oavsiktligt lägga till list instanser där ErrorList instanser förväntas. Detta är ett problem eftersom till skillnad från en enkel list vet en ErrorList hur den ska hantera instanser av ValidationError.

De flesta användningsfall som motiverade användning av dessa privata API:er täcks nu av den nyligen introducerade Form.add_error()-metoden:

# Old pattern:
try:
    ...
except ValidationError as e:
    self._errors = e.update_error_dict(self._errors)

# New pattern:
try:
    ...
except ValidationError as e:
    self.add_error(None, e)

Om du behöver både Django <= 1.6 och 1.7-kompatibilitet kan du inte använda Form.add_error() eftersom det inte var tillgängligt före Django 1.7, men du kan använda följande lösning för att konvertera valfri lista till ErrorList:

try:
    ...
except ValidationError as e:
    self._errors = e.update_error_dict(self._errors)

# Additional code to ensure ``ErrorDict`` is exclusively
# composed of ``ErrorList`` instances.
for field, error_list in self._errors.items():
    if not isinstance(error_list, self.error_class):
        self._errors[field] = self.error_class(error_list)

Beteendet hos `LocMemCache` när det gäller pickle-fel¶

En inkonsekvens fanns i tidigare versioner av Django angående hur pickle-fel hanteras av olika cache-backends. django.core.cache.backends.locmem.LocMemCache brukade misslyckas tyst när ett sådant fel inträffar, vilket är inkonsekvent med andra backends och leder till cache-specifika fel. Detta har åtgärdats i Django 1.7, se #21200 för mer information.

Cache-nycklar genereras nu från förfrågningens absoluta URL¶

Tidigare versioner av Django genererade cache-nycklar med hjälp av en förfrågnings sökväg och frågesträng men inte schema eller värd. Om en Django-applikation betjänade flera underdomäner eller domäner kunde cache-nycklar kollidera. I Django 1.7 varierar cache-nycklarna med den absoluta URL:en för begäran, inklusive schema, värd, sökväg och frågesträng. Till exempel genereras URL-delen av en cache-nyckel nu från https://www.example.com/path/to/?key=val snarare än /path/to/?key=val. De cache-nycklar som genereras av Django 1.7 kommer att skilja sig från de nycklar som genereras av äldre versioner av Django. Efter uppgradering till Django 1.7 kommer den första begäran till en tidigare cachad URL att vara en cache-miss.

Skicka `None` till `Manager.db_manager()`¶

I tidigare versioner av Django var det möjligt att använda db_manager(using=None) på en modellhanterarinstans för att få en hanterarinstans som använder standardroutingbeteende och åsidosätter all manuellt specificerad databasrouting. I Django 1.7 kommer ett värde på None som skickas till db_manager att producera en router som behåller all manuellt tilldelad databasrouting - hanteraren kommer inte att återställas. Detta var nödvändigt för att lösa en inkonsekvens i hur routningsinformation kaskadkopplades över sammanfogningar. Se #13724 för mer detaljer.

`pytz` kan behövas¶

Om ditt projekt hanterar datum före 1970 eller efter 2037 och Django ger upphov till ett ValueError när det möter dem, måste du installera pytz. Du kan påverkas av detta problem om du använder Djangos tidszonsrelaterade datumformat eller django.contrib.syndication.

Strategi för omdirigering av admininloggning¶

Historiskt sett har Django-adminsidan skickat begäran från en obehörig eller oautentiserad användare direkt till inloggningsvyn, utan HTTP-omdirigering. I Django 1.7 ändrades detta beteende för att överensstämma med ett mer traditionellt arbetsflöde där alla obehöriga förfrågningar till en adminsida kommer att omdirigeras (med HTTP-statuskod 302) till inloggningssidan, med parametern next inställd på den refererande sökvägen. Användaren kommer att omdirigeras dit efter en lyckad inloggning.

Observera också att inloggningsformuläret för admin har uppdaterats så att det inte innehåller fältet this_is_the_login_form (nu oanvänt) och koden ValidationError har ställts in på den mer vanliga nyckeln invalid_login.

`select_for_update()` kräver en transaktion¶

Historiskt sett har frågor som använder select_for_update() kunnat köras i autocommit-läge, utanför en transaktion. Före Django 1.6 tillät Djangos automatiska transaktionsläge att detta användes för att låsa poster tills nästa skrivoperation. Django 1.6 introducerade autocommit på databasnivå; sedan dess upphäver exekvering i ett sådant sammanhang effekten av select_for_update(). Det antas därför nu vara ett fel och ger upphov till ett undantag.

Denna ändring gjordes eftersom sådana fel kan orsakas av att inkludera en app som förväntar sig globala transaktioner (t.ex. ATOMIC_REQUESTS <DATABASE-ATOMIC_REQUESTS>` inställd på True), eller Djangos gamla autocommit-beteende, i ett projekt som körs utan dem; och vidare kan sådana fel manifestera sig som datakorruptionsbuggar. Det gjordes också i Django 1.6.3.

Denna ändring kan orsaka testfel om du använder select_for_update() i en testklass som är en underklass av TransactionTestCase snarare än TestCase.

Bidragande mellanprogram borttagna från standard `MIDDLEWARE_CLASSES`¶

Refaktorn app-loading refactor avförde användning av modeller från appar som inte är en del av inställningen INSTALLED_APPS. Detta exponerade en inkompatibilitet mellan standardinställningen INSTALLED_APPS och MIDDLEWARE_CLASSES i de globala standardinställningarna (django.conf.global_settings). För att synkronisera dessa inställningar och förhindra deprecation-varningar när man gör saker som att testa återanvändbara appar med minimala inställningar, togs SessionMiddleware, AuthenticationMiddleware och MessageMiddleware bort från standardinställningarna. Dessa klasser kommer fortfarande att ingå i de standardinställningar som genereras av startproject. De flesta projekt kommer inte att påverkas av denna ändring, men om du inte tidigare har deklarerat MIDDLEWARE_CLASSES i dina projektinställningar och förlitat dig på den globala standardinställningen bör du se till att de nya standardinställningarna överensstämmer med ditt projekts behov. Du bör också kontrollera om det finns någon kod som har direkt åtkomst till django.conf.global_settings.MIDDLEWARE_CLASSES.

Diverse¶

Metoden django.core.files.uploadhandler.FileUploadHandler.new_file() får nu en ytterligare parameter content_type_extra. Om du har en anpassad FileUploadHandler som implementerar new_file(), se till att den accepterar denna nya parameter.
ModelFormSet raderar inte längre instanser när save(commit=False) anropas. Se can_delete för instruktioner om hur du manuellt tar bort objekt från borttagna formulär.
Laddning av tomma fixturer ger en RuntimeWarning istället för att ge upphov till CommandError.
django.contrib.staticfiles.views.serve() kommer nu att ge upphov till ett Http404 undantag istället för ImproperlyConfigured när DEBUG är False. Denna ändring tar bort behovet av att villkorligt lägga till vyn i din root URLconf, vilket i sin tur gör det säkert att vända på namnet. Den tar också bort möjligheten för besökare att generera falska HTTP 500-fel genom att begära statiska filer som inte finns eller som inte har samlats in ännu.
Metoden django.db.models.Model.__eq__() är nu definierad på ett sätt där instanser av en proxymodell och dess basmodell anses vara lika när primära nycklar matchar. Tidigare ansågs endast instanser av exakt samma klass vara lika vid matchning av primärnycklar.
Metoden django.db.models.Model.__eq__() har ändrats så att två Model-instanser utan primärnyckelvärden inte kommer att betraktas som lika (såvida de inte är samma instans).
Metoden django.db.models.Model.__hash__() kommer nu att ge upphov till TypeError när den anropas på en instans utan ett primärnyckelvärde. Detta görs för att undvika mutabla __hash__-värden i behållare.
AutoField-kolumner i SQLite-databaser kommer nu att skapas med hjälp av alternativet AUTOINCREMENT, som garanterar monotona ökningar. Detta kommer att leda till att numreringsbeteendet för primärnycklar ändras i SQLite och blir konsekvent med de flesta andra SQL-databaser. Detta gäller endast för nyskapade tabeller. Om du har en databas som skapats med en äldre version av Django måste du migrera den för att dra nytta av den här funktionen. Du kan till exempel göra följande:
1. Använd dumpdata för att spara dina data.
2. Byt namn på den befintliga databasfilen (behåll den som säkerhetskopia).
3. Kör migrate för att skapa det uppdaterade schemat.
4. Använd loaddata för att importera de fixturer som du exporterade i (1).
django.contrib.auth.models.AbstractUser definierar inte längre en get_absolute_url()-metod. Den gamla definitionen returnerade "/users/%s/" % urlquote(self.username) vilket var godtyckligt eftersom applikationer kanske eller kanske inte definierar en sådan webbadress i urlpatterns. Definiera en get_absolute_url()-metod på ditt eget anpassade användarobjekt eller använd ABSOLUTE_URL_OVERRIDES om du vill ha en URL för din användare.
Funktionaliteten för servering av statiska tillgångar i klassen django.test.LiveServerTestCase har förenklats: Nu kan den bara servera innehåll som redan finns i STATIC_ROOT när tester körs. Möjligheten att transparent servera alla statiska tillgångar (på samma sätt som man får med DEBUG = True vid utvecklingstid) har flyttats till en ny klass som lever i applikationen staticfiles (den som faktiskt ansvarar för en sådan funktion): django.contrib.staticfiles.testing.StaticLiveServerTestCase. Med andra ord är LiveServerTestCase i sig mindre kraftfull men har samtidigt mindre magi.

Skälet till detta är att ta bort beroendet av icke-contrib-kod på contrib-applikationer.
Den gamla URI-syntaxen för cache (t.ex. "locmem://") stöds inte längre. Den fungerade fortfarande, även om den inte var dokumenterad eller officiellt stödd. Om du fortfarande använder den, uppdatera till den nuvarande CACHES-syntaxen.
Standardordningen för Form-fält i händelse av arv har ändrats för att följa normal Python MRO. Fält upptäcks nu genom att iterera genom MRO i omvänd ordning, där den översta klassen kommer sist. Detta påverkar dig bara om du förlitade dig på standardfältordningen medan du hade fält definierade på både den aktuella klassen och på en överordnad Form.
Argumentet required i SelectDateWidget har tagits bort. Denna widget respekterar nu formulärfältets is_required-attribut som andra widgets.
Widget.is_hidden är nu en skrivskyddad egenskap som får sitt värde genom att introspektera förekomsten av input_type == 'hidden'.
select_related() kedjar nu på samma sätt som andra liknande anrop som prefetch_related. Det vill säga, select_related('foo', 'bar') är likvärdigt med select_related('foo').select_related('bar'). Tidigare skulle det senare ha varit likvärdigt med select_related('bar').
GeoDjango har inte längre stöd för GEOS < 3.1.
Metoden init_connection_state för databasbackends körs nu i autocommit-läge (om du inte ställer in :setting:AUTOCOMMIT <DATABASE-AUTOCOMMIT> till False). Om du underhåller en anpassad databasbackend bör du kontrollera den metoden.
Attributet django.db.backends.BaseDatabaseFeatures.allows_primary_key_0 har bytt namn till allows_auto_pk_0 för att bättre beskriva det. Det är True för alla databasbackends som ingår i Django utom MySQL som tillåter primära nycklar med värdet 0. Det förbjuder bara autoincrement primära nycklar med värde 0.
Skuggning av modellfält som definieras i en överordnad modell har förbjudits eftersom detta skapar tvetydighet i det förväntade modellbeteendet. Dessutom resulterar kolliderande fält i modellens arvshierarki i ett systemkontrollfel. Om du t.ex. använder multi-inheritance måste du definiera anpassade primärnyckelfält i överordnade modeller, annars kommer standardfälten id att krocka. Se Multipel arvsmassa för mer information.
django.utils.translation.parse_accept_lang_header() returnerar nu lokala med små bokstäver, istället för det fall som det tillhandahölls. Eftersom lokalspråk bör behandlas skiftlägesokänsligt gör detta att vi kan påskynda lokalspårningen.
django.utils.translation.get_language_from_path() och django.utils.translation.trans_real.get_supported_language_variant() har nu inte längre ett stödd argument.
Vyn shortcut i django.contrib.contenttypes.views stöder nu protokollrelativa webbadresser (t.ex. //example.com).
GenericRelation har nu stöd för ett valfritt argument related_query_name. Om du anger related_query_name läggs en relation från det relaterade objektet tillbaka till innehållstypen för filtrering, ordning och andra frågeoperationer.
När du kör tester på PostgreSQL kommer USER att behöva läsbehörighet till den inbyggda postgres-databasen. Detta är i stället för det tidigare beteendet att ansluta till den faktiska icke-testdatabasen.
Som en del av System check framework, fields, models, and model managers implementerar alla en check() metod som är registrerad med check framework. Om du har en befintlig metod som heter check() på ett av dessa objekt, måste du byta namn på den.
Som nämnts ovan i avsnittet ”Cache” i ”Mindre funktioner”, kommer en definition av argumentet TIMEOUT i inställningen CACHES som None att ställa in cache-nycklarna som ”non-expiring”. Tidigare, med memcache-backend, skulle en TIMEOUT på 0 ställa in nycklar som inte upphör att gälla, men detta var inkonsekvent med set-and-expire-beteendet (dvs. ingen cachelagring) i set("key", "value", timeout=0). Om du vill ha nycklar som inte löper ut, uppdatera dina inställningar så att du använder None istället för 0 eftersom den senare nu också anger set-and-expire i inställningarna.
Hanteringskommandona sql* respekterar nu metoden allow_migrate() i DATABASE_ROUTERS. Om du har modeller som synkroniserats till databaser som inte är standarddatabaser, använd flaggan --database för att få SQL för dessa modeller (tidigare inkluderades de alltid i utdata).
Avkodning av frågesträngen från webbadresser faller nu tillbaka till ISO-8859-1-kodningen när inmatningen inte är giltig UTF-8.
Med tillägget av django.contrib.auth.middleware.SessionAuthenticationMiddleware till standardprojektmallen (endast före 1.7.2) måste en databas skapas innan du öppnar en sida med runserver.
Tillägget av argumentet schemes till URLValidator kommer att framstå som en bakåtkompatibel förändring om du tidigare använde ett anpassat reguljärt uttryck för att validera scheman. Alla scheman som inte listas i schemes kommer att misslyckas med valideringen, även om det reguljära uttrycket matchar den angivna URL:en.

Funktioner som inte längre är aktuella i 1.7¶

`django.core.cache.get_cache`¶

django.core.cache.get_cache har ersatts av django.core.cache.caches.

`django.utils.dictconfig`/django.utils.importlib`¶

django.utils.dictconfig och django.utils.importlib var kopior av logging.config respektive importlib som tillhandahölls för Python-versioner före 2.7. De har blivit föråldrade.

`django.utils.module_loading.import_by_path`¶

Den nuvarande funktionen django.utils.module_loading.import_by_path fångar upp AttributeError, ImportError och ValueError undantag och återställer ImproperlyConfigured. Sådan undantagsmaskering gör det onödigt svårt att diagnostisera problem med cirkulär import, eftersom det får det att se ut som om problemet kommer inifrån Django. Det har utgått till förmån för import_string().

`django.utils.tzinfo`¶

django.utils.tzinfo tillhandahöll två tzinfo-underklasser, LocalTimezone och FixedOffset. De har utgått till förmån för mer korrekta alternativ som tillhandahålls av django.utils.timezone, django.utils.timezone.get_default_timezone() och django.utils.timezone.get_fixed_timezone().

`django.utils.unittest`¶

django.utils.unittest gav enhetlig tillgång till unittest2-biblioteket på alla Python-versioner. Eftersom unittest2 blev standardbibliotekets unittest-modul i Python 2.7, och Django 1.7 tappar stöd för äldre Python-versioner, är denna modul inte användbar längre. Den har blivit avskriven. Använd unittest istället.

`django.utils.datastrukturer.SortedDict`¶

Eftersom OrderedDict lades till i standardbiblioteket i Python 2.7, behövs inte längre SortedDict och har utgått.

De två ytterligare, föråldrade metoderna som tillhandahålls av SortedDict (insert() och value_for_index()) har tagits bort. Om du förlitade dig på dessa metoder för att ändra strukturer som formulärfält, bör du nu behandla dessa OrderedDict som oföränderliga objekt och åsidosätta dem för att ändra deras innehåll.

Till exempel kanske du vill åsidosätta MyFormClass.base_fields (även om detta attribut inte anses vara ett offentligt API) för att ändra ordningen på fält för alla MyFormClass-instanser; eller på liknande sätt kan du åsidosätta self.fields inifrån MyFormClass.__init__(), för att ändra fälten för en viss formulärinstans. Till exempel (från Django själv):

PasswordChangeForm.base_fields = OrderedDict(
    (k, PasswordChangeForm.base_fields[k])
    for k in ["old_password", "new_password1", "new_password2"]
)

Anpassad SQL-plats för modellpaket¶

Tidigare, om modeller organiserades i ett paket (myapp/models/) snarare än bara myapp/models.py, skulle Django leta efter inledande SQL-data i myapp/models/sql/. Denna bugg har åtgärdats så att Django söker i myapp/sql/ som dokumenterat. Efter att detta problem åtgärdades lades migreringar till som avregistrerar initial SQL-data. Även om denna ändring fortfarande existerar är avskrivningen irrelevant eftersom hela funktionen kommer att tas bort i Django 1.9.

Omorganisering av `django.contrib.sites`¶

django.contrib.sites ger reducerad funktionalitet när den inte finns i INSTALLED_APPS. App-loading refactor lägger till några begränsningar i den situationen. Som en följd av detta flyttades två objekt och de gamla platserna är föråldrade:

RequestSite finns nu i django.contrib.sites.requests.
get_current_site() finns nu i django.contrib.sites.shortcuts.

attributet `declared_fieldsets` för `ModelAdmin`¶

ModelAdmin.declared_fieldsets har blivit föråldrat. Trots att det är ett privat API kommer det att gå igenom en vanlig deprecation-väg. Detta attribut användes mest av metoder som kringgick ModelAdmin.get_fieldsets() men detta ansågs vara en bugg och har åtgärdats.

Omorganisering av `django.contrib.contenttypes`¶

Eftersom django.contrib.contenttypes.generic definierade både admin- och modellrelaterade objekt, kunde en import av denna modul utlösa oväntade sidoeffekter. Som en följd av detta delades dess innehåll upp i contenttypes undermoduler och modulen django.contrib.contenttypes.generic är avskriven:

GenericForeignKey och GenericRelation finns nu i fields.
BaseGenericInlineFormSet och generic_inlineformset_factory() finns nu i forms.
GenericInlineModelAdmin, GenericStackedInline och GenericTabularInline finns nu i admin.

`syncdb`¶

Kommandot syncdb har utgått till förmån för det nya kommandot migrate`. migrate tar samma argument som syncdb brukade göra plus några till, så det är säkert att bara ändra namnet du anropar och inget annat.

modulerna `util` byter namn till `utils`¶

Följande instanser av util.py i Djangos kodbas har bytt namn till utils.py i ett försök att förena alla util- och utils-referenser:

django.contrib.admin.util
django.contrib.gis.db.backends.util
django.db.backends.util
django.forms.util

metoden `get_formsets` för `ModelAdmin`¶

ModelAdmin.get_formsets har utgått till förmån för den nya get_formsets_with_inlines`(), för att bättre hantera fallet att selektivt visa inlines på en ModelAdmin.

`IPAddressField`¶

Fälten django.db.models.IPAddressField och django.forms.IPAddressField har utgått till förmån för django.db.models.GenericIPAddressField och django.forms.GenericIPAddressField.

metoden `BaseMemcachedCache._get_memcache_timeout`¶

Metoden BaseMemcachedCache._get_memcache_timeout() har bytt namn till get_backend_timeout(). Trots att det är ett privat API kommer det att gå igenom den normala utfasningen.

Alternativ för serialisering av naturliga nycklar¶

Alternativen --natural och -n för dumpdata har utgått. Använd dumpdata --natural-foreign istället.

På samma sätt har argumentet use_natural_keys för serializers.serialize() utgått. Använd use_natural_foreign_keys istället.

Sammanslagning av argumenten `POST` och `GET` till `WSGIRequest.REQUEST`¶

Det var redan starkt rekommenderat att du använder GET och POST istället för REQUEST, eftersom de förra är mer explicita. Egenskapen REQUEST är föråldrad och kommer att tas bort i Django 1.9.

klassen `django.utils.datastructures.MergeDict`¶

MergeDict finns främst för att stödja sammanslagning av POST och GET argument till en REQUEST egenskap på WSGIRequest. För att slå samman ordböcker, använd dict.update() istället. Klassen MergeDict är föråldrad och kommer att tas bort i Django 1.9.

Språkkoderna `zh-cn`, `zh-tw` och `fy-nl`¶

De språkkoder som för närvarande används för förenklad kinesiska zh-cn, traditionell kinesiska zh-tw och (väst)fransyska fy-nl är föråldrade och bör ersättas av språkkoderna zh-hans, zh-hant respektive fy. Om du använder dessa språkkoder bör du byta namn på locale-katalogerna och uppdatera dina inställningar så att de återspeglar dessa ändringar. De föråldrade språkkoderna kommer att tas bort i Django 1.9.

funktionen `django.utils.functional.memoize`¶

Funktionen memoize är föråldrad och bör ersättas av dekoratorn functools.lru_cache (tillgänglig från Python 3.2 och framåt).

Django levererar en backport av denna dekorator för äldre Python-versioner och den finns tillgänglig på django.utils.lru_cache.lru_cache. Den föråldrade funktionen kommer att tas bort i Django 1.9.

Geografiska webbplatskartor¶

Google har dragit tillbaka stödet för Geo Sitemaps-formatet. Därför är Djangos stöd för Geo Sitemaps utdaterat och kommer att tas bort i Django 1.8.

Skicka anropsbara argument till queryset-metoder¶

Kallbara argument för querysets var en odokumenterad funktion som var opålitlig. Den har utrangerats och kommer att tas bort i Django 1.9.

Kallbara argument utvärderades när en queryset konstruerades i stället för när den utvärderades, vilket innebar att den här funktionen inte gav någon fördel jämfört med att utvärdera argumenten innan de skickades till queryset och skapade förvirring om att argumenten kunde ha utvärderats vid query-tidpunkten.

inställning `ADMIN_FOR`¶

Funktionen ADMIN_FOR, som är en del av admindocs, har tagits bort. Du kan ta bort inställningen från din konfiguration när det passar dig.

`SplitDateTimeWidget` med `DateTimeField`¶

stöd för SplitDateTimeWidget i DateTimeField är föråldrat, använd SplitDateTimeWidget med SplitDateTimeField istället.

`validera`¶

Hanteringskommandot validate är utdaterat till förmån för kommandot check.

`django.core.management.BaseCommand`¶

flaggan requires_model_validation har tagits bort till förmån för den nya flaggan requires_system_checks. Om den senare flaggan saknas används värdet för den förra flaggan. Att definiera både requires_system_checks och requires_model_validation resulterar i ett fel.

Metoden check() har ersatt den gamla metoden validate().

validerare för `ModelAdmin`¶

Attributen ModelAdmin.validator_class och default_validator_class är avförda till förmån för det nya attributet checks_class.

Metoden ModelAdmin.validate() är föråldrad till förmån för ModelAdmin.check().

Modulen django.contrib.admin.validation är föråldrad.

`django.db.backends.databasvalidering.validate_field`¶

Denna metod har utgått till förmån för den nya metoden check_field. Funktionaliteten som krävs av check_field() är samma som den som tillhandahålls av validate_field(), men utdataformatet är annorlunda. Tredjeparts databasbackends som behöver denna funktionalitet bör tillhandahålla en implementation av check_field().

Laddar `ssi och `url` malltaggar från `future` bibliotek¶

Django 1.3 introducerade {% load ssi from future %} och {% load url from future %} syntax för framåtkompatibilitet av ssi och url malltaggar. Denna syntax är nu föråldrad och kommer att tas bort i Django 1.9. Du kan helt enkelt ta bort {% load ... from future %}-taggarna.

`django.utils.text.javascript_quote`¶

javascript_quote() var en odokumenterad funktion som fanns i django.utils.text. Den användes internt i vyn javascript_catalog() vars implementation ändrades till att använda json.dumps() istället. Om du förlitar dig på denna funktion för att tillhandahålla säker utdata från opålitliga strängar, bör du använda django.utils.html.escapejs eller escapejs mallfiltret. Om allt du behöver är att generera giltiga JavaScript-strängar kan du helt enkelt använda json.dumps().

`fix_ampersands` utils-metod och mallfilter¶

Metoden django.utils.html.fix_ampersands och mallfiltret fix_ampersands är föråldrade, eftersom escapingen av ampersands redan tas om hand av Djangos standard HTML-escapingfunktioner. Att kombinera detta med fix_ampersands skulle antingen resultera i dubbel escaping eller, om utdata antas vara säker, en risk för att införa XSS-sårbarheter. Tillsammans med fix_ampersands är django.utils.html.clean_html utfasad, en odokumenterad funktion som anropar fix_ampersands. Eftersom detta är en accelererad deprecation kommer fix_ampersands och clean_html att tas bort i Django 1.8.

Omorganisering av testinställningar för databaser¶

Alla databasinställningar med prefixet TEST_ har utgått till förmån för poster i en TEST-ordbok i databasinställningarna. De gamla inställningarna kommer att stödjas fram till Django 1.9. För bakåtkompatibilitet med äldre versioner av Django kan du definiera båda versionerna av inställningarna så länge de matchar.

Stöd för FastCGI¶

FastCGI-stöd via hanteringskommandot runfcgi kommer att tas bort i Django 1.9. Distribuera ditt projekt med hjälp av WSGI.

Flyttade objekt i `contrib.sites`¶

Efter app-loading refactor behövde två objekt i django.contrib.sites.models flyttas eftersom de måste vara tillgängliga utan att importera django.contrib.sites.models när django.contrib.sites inte är installerat. Importera RequestSite från django.contrib.sites.requests och get_current_site() från django.contrib.sites.shortcuts. De gamla importplatserna kommer att fungera fram till Django 1.9.

`django.forms.forms.get_declared_fields()`¶

Django använder inte längre denna funktion internt. Även om det är ett privat API kommer det att gå igenom den normala utfasningscykeln.

API:er för privata sökfrågor¶

Privata API:er django.db.models.sql.where.WhereNode.make_atom() och django.db.models.sql.where.Constraint är utfasade till förmån för den nya :doc:``custom lookups API </ref/models/lookups>`.

Funktioner borttagna i 1.7¶

Dessa funktioner har nått slutet av sin utfasningscykel och tas bort i Django 1.7. Se Funktioner som inte längre är aktuella i 1.5 för detaljer, inklusive hur man tar bort användningen av dessa funktioner.

django.utils.simplejson är borttagen.
django.utils.itercompat.product har tagits bort.
INSTALLED_APPS och TEMPLATE_DIRS korrigeras inte längre från en vanlig sträng till en tupel.
HttpResponse, SimpleTemplateResponse, TemplateResponse, render_to_response(), index(), och sitemap() tar inte längre ett mimetype argument
HttpResponse konsumerar omedelbart sitt innehåll om det är en iterator.
Inställningen AUTH_PROFILE_MODULE och metoden get_profile() i User-modellen har tagits bort.
Ledningskommandot cleanup har tagits bort.
Skriptet daily_cleanup.py har tagits bort.
select_related() har inte längre ett djup nyckelordsargument.
Funktionerna get_warnings_state()/restore_warnings_state() från django.test.utils och save_warnings_state()/ restore_warnings_state() django.test.*TestCase tas bort.
Metoden check_for_test_cookie i AuthenticationForm har tagits bort.
Den version av django.contrib.auth.views.password_reset_confirm() som stöder base36-kodade användar-ID (django.contrib.auth.views.password_reset_confirm_uidb36) tas bort.
Mix-in django.utils.encoding.StrAndUnicode tas bort.