Django 1.0 release notes¶
Välkommen till Django 1.0!
Vi har sett fram emot detta ögonblick i över tre år, och nu är det äntligen här. Django 1.0 representerar den största milstolpen i Djangos utveckling hittills: ett webbramverk som en grupp perfektionister verkligen kan vara stolta över.
Django 1.0 representerar över tre års utveckling av ett Open Source-projekt. Django har fått bidrag från hundratals utvecklare, har översatts till femtio språk och används idag av utvecklare på alla kontinenter och i alla typer av jobb.
En intressant historisk notering: när Django först släpptes i juli 2005 kom den första versionen av Django från ett internt arkiv med revisionsnummer 8825. Django 1.0 representerar revision 8961 av vårt offentliga arkiv. Det verkar passande att vår 1.0-utgåva kommer i det ögonblick då bidrag från samhället går förbi de som görs privat.
Stabilitet och framåtriktad kompatibilitet¶
Utgåvan av Django 1.0 kommer med ett löfte om API-stabilitet och framåtkompatibilitet. I ett nötskal betyder detta att kod som du utvecklar mot Django 1.0 kommer att fortsätta att fungera mot 1.1 oförändrat, och du bör bara behöva göra mindre ändringar för alla 1.X-versioner.
Se API-stabilitetsguide för fullständig information.
Bakåtkompatibla förändringar¶
Django 1.0 har ett antal förändringar som inte är bakåtkompatibla med Django 0.96. Om du har appar som är skrivna mot Django 0.96 som du behöver porta, se vår detaljerade portningsguide:
En fullständig lista över ändringar som inte är bakåtkompatibla finns på https://code.djangoproject.com/wiki/BackwardsIncompatibleChanges.
Vad är nytt i Django 1.0¶
En mycket!
Sedan Django 0.96 har vi gjort över 4 000 kodöverföringar, åtgärdat mer än 2 000 buggar och redigerat, lagt till eller tagit bort cirka 350 000 rader kod. Vi har också lagt till 40 000 rader ny dokumentation och kraftigt förbättrat det som redan fanns där.
Faktum är att ny dokumentation är en av våra favoritfunktioner i Django 1.0, så vi kan lika gärna börja där. För det första finns det en ny dokumentationswebbplats:
Dokumentationen har förbättrats avsevärt, rensats upp och i allmänhet gjorts fantastisk. Det finns nu dedikerad sökning, index och mycket mer.
Vi kan omöjligen dokumentera allt som är nytt i 1.0, men dokumentationen kommer att vara din definitiva guide. Överallt där du ser något som:
Denna funktion är ny i Django 1.0
Du kommer att veta att du tittar på något nytt eller förändrat.
De andra stora höjdpunkterna i Django 1.0 är:
Omarbetad admin-applikation¶
Djangos administrativa gränssnitt (django.contrib.admin) har helt omarbetats; admin-definitioner är nu helt frikopplade från modelldefinitioner (ingen mer class Admin-deklaration i modeller!), omskrivna för att använda Djangos nya formulärhanteringsbibliotek (introducerat i 0.96-utgåvan som django.newforms, och nu tillgängligt som helt enkelt django.forms) och omdesignat med tanke på utbyggbarhet och anpassning. Fullständig dokumentation för admin-applikationen finns tillgänglig online i den officiella Django-dokumentationen:
Se admin-referens för detaljer
Förbättrad Unicode-hantering¶
Djangos interna funktioner har omarbetats för att använda Unicode genomgående; detta förenklar drastiskt uppgiften att hantera icke-västeuropeiskt innehåll och data i Django. Dessutom har verktygsfunktioner tillhandahållits för att underlätta interoperabilitet med tredjepartsbibliotek och system som kanske eller kanske inte hanterar Unicode på ett elegant sätt. Detaljer finns i Djangos dokumentation om Unicode-hantering.
Se Unicode-data.
En förbättrad ORM¶
Djangos objektrelationella mappare - den komponent som tillhandahåller mappningen mellan Djangos modellklasser och din databas, och som förmedlar dina databasfrågor - har förbättrats dramatiskt genom en massiv refaktorisering. För de flesta användare av Django är detta bakåtkompatibelt; det publika API:et för databasfrågor genomgick några mindre förändringar, men de flesta uppdateringarna ägde rum i ORM:s interna delar. En guide till ändringarna, inklusive bakåtkompatibla modifieringar och omnämnanden av nya funktioner som öppnats upp genom denna refaktorisering, finns tillgänglig på Django wiki.
Automatisk escaping av mallvariabler¶
För att ge förbättrad säkerhet mot XSS-sårbarheter (cross-site scripting) escapar Djangos mallsystem nu automatiskt utdata från variabler. Detta beteende är konfigurerbart och gör att både variabler och större mallkonstruktioner kan markeras som säkra (kräver ingen escaping) eller osäkra (kräver escaping). En fullständig guide till den här funktionen finns i dokumentationen för taggen autoescape.
django.contrib.gis (GeoDjango)¶
Detta är ett projekt som har pågått i över ett år och som ger Django GIS-stöd (Geographic Information Systems) i världsklass, i form av en contrib-applikation. Dess dokumentation underhålls för närvarande externt och kommer inom kort att slås samman med Djangos huvuddokumentation. Ett stort tack till Justin Bronn, Jeremy Dunck, Brett Hoerner och Travis Pinney för deras ansträngningar att skapa och slutföra denna funktion.
Se GeoDjango för detaljer.
Pluggbar lagring av filer¶
Djangos inbyggda FileField och ImageField kan nu dra nytta av pluggbara backends för fillagring, vilket möjliggör omfattande anpassning av var och hur uppladdade filer lagras av Django. För detaljer, se fildokumentationen; stort tack till Marty Alchin för det hårda arbetet med att få detta slutfört.
Jython-kompatibilitet¶
Tack vare mycket arbete från Leo Soto under ett Google Summer of Code-projekt har Djangos kodbas omarbetats för att ta bort inkompatibiliteter med Jython, en implementering av Python skriven i Java, som kör Python-kod på Java Virtual Machine. Django är nu kompatibelt med den kommande versionen Jython 2.5.
Generiska relationer i formulär och administration¶
Klasser ingår nu i django.contrib.contenttypes som kan användas för att stödja generiska relationer i både administratörsgränssnittet och i slutanvändarformulär. Se :ref:dokumentationen för generiska relationer <generic-relations> för mer information.
skillnad mellan INSERT och UPDATE¶
Även om Djangos standardbeteende att låta en modells save()-metod automatiskt avgöra om en INSERT eller en UPDATE ska utföras på SQL-nivå är lämpligt för de flesta fall, finns det enstaka situationer där det är användbart att tvinga fram det ena eller det andra. Därför kan modeller nu stödja en ytterligare parameter till save() som kan tvinga fram en specifik operation.
Se Tvinga fram en INSERT eller UPDATE för mer information.
Dela upp CacheMiddleware¶
Djangos CacheMiddleware har delats upp i tre klasser: CacheMiddleware i sig existerar fortfarande och behåller all sin tidigare funktionalitet, men det är nu byggt från två separata middleware-klasser som hanterar de två delarna av caching (infoga i och läsa från cachen) separat, vilket ger ytterligare flexibilitet för situationer där kombinationen av dessa funktioner i en enda middleware utgjorde problem.
Fullständig information, inklusive uppdaterade anvisningar om lämplig användning, finns i dokumentationen om cachelagring.
Refaktoriserade django.contrib.comments¶
Som en del av ett Google Summer of Code-projekt genomförde Thejaswi Puthraya en större omskrivning och refaktorisering av Djangos medföljande kommentarssystem, vilket kraftigt ökade dess flexibilitet och anpassningsbarhet.
Borttagning av föråldrade funktioner¶
Ett antal funktioner och metoder som tidigare hade markerats som föråldrade, och som var planerade att tas bort före 1.0-utgåvan, finns inte längre i Django. Dessa inkluderar import av formulärbiblioteket från django.newforms (som nu helt enkelt finns på django.forms), hjälpfunktionerna form_for_model och form_for_instance (som har ersatts av ModelForm) och ett antal föråldrade funktioner som ersattes av dispatcher, filuppladdning och filförvaring som introducerades i Django 1.0 alpha-versionerna.
Kända problem¶
Vi har gjort vårt bästa för att göra Django 1.0 så solid som möjligt, men tyvärr finns det ett par problem som vi känner till i utgåvan.
Arv av modell för flera tabeller med to_field¶
Om du använder :ref:multiple table model inheritance <multi-table-inheritance>, var medveten om denna varning: barnmodeller som använder en anpassad parent_link och to_field kommer att orsaka fel i databasintegriteten. En uppsättning modeller som följande är inte giltiga:
class Parent(models.Model):
name = models.CharField(max_length=10)
other_value = models.IntegerField(unique=True)
class Child(Parent):
father = models.OneToOneField(
Parent, primary_key=True, to_field="other_value", parent_link=True
)
value = models.IntegerField()
Denna bugg kommer att åtgärdas i nästa version av Django.
Förbehåll med stöd för vissa databaser¶
Django försöker att stödja så många funktioner som möjligt på alla databasbackends. Alla databasbackends är dock inte likadana, och i synnerhet skiljer sig många av de stödda databaserna mycket från version till version. Det är en bra idé att kolla in vår noter om stödda databaser:
