--- title: "Django 1.6 versionsinformation" version: 6.0 locale: sv source: https://docs.djangoproject.com/sv/6.0/releases/1.6/ canonical: https://djangodocs.dev/sv/6.0/releases/1.6/ --- # Django 1.6 versionsinformation > **Note** > > Tillägnad Malcolm Tredinnick > > Den 17 mars 2013 förlorade Djangoprojektet och den fria programvarugemenskapen en mycket kär vän och utvecklare. > > Malcolm var en långvarig bidragsgivare till Django, en föredömlig medlem av gemenskapen, ett briljant sinne och en vän. Hans bidrag till Django - och till många andra projekt med öppen källkod - är nästan omöjliga att räkna upp. Många i Djangos kärnteam fick sina första patchar granskade av honom; hans mentorskap berikade oss. Hans omtanke, tålamod och hängivenhet kommer alltid att vara en inspiration för oss. > > Denna version av Django är för Malcolm. > > – Django-utvecklarna *6 november 2013* Välkommen till Django 1.6! Dessa versionsinformation täcker [nya funktioner](#whats-new-1-6), samt några [bakåtkompatibla ändringar](#backwards-incompatible-1-6) som du bör vara medveten om när du uppgraderar från Django 1.5 eller äldre versioner. Vi har också tagit bort några funktioner, som beskrivs i [vår utfasningsplan](/sv/6.0/internals/deprecation/#deprecation-removed-in-1-6), och vi har [börjat utfasningsprocessen för vissa funktioner](#deprecated-features-1-6). ## Kompatibilitet med Python Django 1.6, precis som Django 1.5, kräver Python 2.6.5 eller senare. Python 3 stöds också officiellt. Vi rekommenderar **starkt** den senaste mindre utgåvan för varje Python-serie som stöds (2.6.X, 2.7.X, 3.2.X och 3.3.X). Django 1.6 kommer att vara den sista utgåvan som stöder Python 2.6; från och med Django 1.7 kommer den minsta Python-versionen som stöds att vara 2.7. Python 3.4 stöds inte, men stöd kommer att läggas till i Django 1.7. ## Vad är nytt i Django 1.6 ### Förenklade standardmallar för projekt och appar De standardmallar som används av [`startproject`](/sv/6.0/ref/django-admin/#django-admin-startproject) och [`startapp`](/sv/6.0/ref/django-admin/#django-admin-startapp) har förenklats och moderniserats. Ramverket [admin](/sv/6.0/ref/contrib/admin/) är nu aktiverat som standard i nya projekt; ramverket [sites](/sv/6.0/ref/contrib/sites/) är det inte längre. Ramverket [clickjacking prevention](/sv/6.0/ref/clickjacking/#clickjacking-prevention) är nu aktiverat och databasen använder SQLite som standard. Om standardmallarna inte passar din smak kan du använda [anpassade projekt- och appmallar](/sv/6.0/ref/django-admin/#custom-app-and-project-templates). ### Förbättrad transaktionshantering Djangos transaktionshantering har setts över. Autocommit på databasnivå är nu aktiverat som standard. Detta gör transaktionshanteringen mer explicit och bör förbättra prestandan. De befintliga API:erna utrangerades och nya API:er infördes, enligt beskrivningen i [transaktionshanteringsdokument](/sv/6.0/topics/db/transactions/). ### Beständiga databasanslutningar Django har nu stöd för att återanvända samma databasanslutning för flera förfrågningar. Detta undviker omkostnaderna för att återupprätta en anslutning i början av varje begäran. För bakåtkompatibilitet är den här funktionen inaktiverad som standard. Se [Beständiga anslutningar](/sv/6.0/ref/databases/#persistent-database-connections) för detaljer. ### Upptäckt av tester i valfri testmodul Django 1.6 levereras med en ny testlöpare som tillåter mer flexibilitet i placeringen av tester. Den tidigare löparen (`django.test.simple.DjangoTestSuiteRunner`) hittade bara tester i modulerna `models.py` och `tests.py` i ett Python-paket i [`INSTALLED_APPS`](/sv/6.0/ref/settings/#std-setting-INSTALLED_APPS). Den nya löparen (`django.test.runner.DiscoverRunner`) använder de testupptäcktsfunktioner som är inbyggda i `unittest2` (versionen av `unittest` i Python 2.7+ standardbiblioteket och levereras med Django). Med testupptäckt kan tester placeras i vilken modul som helst vars namn matchar mönstret `test*.py`. Dessutom måste de testetiketter som tillhandahålls till `./manage.py test` för att nominera specifika tester att köra nu vara fullständiga Python-punktade sökvägar (eller katalogsökvägar), snarare än `applabel.TestCase.test_method_name` pseudosökvägar. Detta gör det möjligt att köra tester var som helst i din kodbas, snarare än bara i [`INSTALLED_APPS`](/sv/6.0/ref/settings/#std-setting-INSTALLED_APPS). För mer information, se [Testning i Django](/sv/6.0/topics/testing/). Denna ändring är bakåtkompatibel; se [backwards-incompatibility notes](#new-test-runner). ### Aggregering med hänsyn till tidszon Stödet för [tidszoner](/sv/6.0/topics/i18n/timezones/) som infördes i Django 1.4 fungerade inte bra med [`QuerySet.dates()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.dates): aggregering utfördes alltid i UTC. Denna begränsning upphävdes i Django 1.6. Använd [`QuerySet.datetimes()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.datetimes) för att utföra tidszonmedveten aggregering på en [`DateTimeField`](/sv/6.0/ref/models/fields/#django.db.models.DateTimeField). ### Stöd för sparpunkter i SQLite Django 1.6 lägger till stöd för sparpunkter i SQLite, med vissa [begränsningar](/sv/6.0/topics/db/transactions/#savepoints-in-sqlite). ### modellfältet `BinaryField` Ett nytt [`django.db.models.BinaryField`](/sv/6.0/ref/models/fields/#django.db.models.BinaryField) modellfält tillåter lagring av rå binär data i databasen. ### Widgets för GeoDjango-formulär GeoDjango tillhandahåller nu [formfält och widgets](/sv/6.0/ref/contrib/gis/forms-api/) för sina geospecialiserade fält. De är OpenLayers-baserade som standard, men de kan anpassas för att använda något annat JS-ramverk. ### kommandot `check` har lagts till för att verifiera kompatibilitet Ett [`check`](/sv/6.0/ref/django-admin/#django-admin-check)-hanteringskommando har lagts till, så att du kan kontrollera om din aktuella konfiguration (för närvarande inriktad på inställningar) är kompatibel med den aktuella versionen av Django. ### [`Model.save()`](/sv/6.0/ref/models/instances/#django.db.models.Model.save) algoritm ändrad Metoden [`Model.save()`](/sv/6.0/ref/models/instances/#django.db.models.Model.save) försöker nu att direkt `UPDATE` databasen om instansen har ett primärnyckelvärde. Tidigare utfördes `SELECT` för att avgöra om `UPDATE` eller `INSERT` behövdes. Den nya algoritmen behöver bara en fråga för att uppdatera en befintlig rad medan den gamla algoritmen behövde två. Se [`Model.save()`](/sv/6.0/ref/models/instances/#django.db.models.Model.save) för mer information. I vissa sällsynta fall rapporterar databasen inte att en matchande rad hittades när du gör en \`\` UPPDATERING\`\`. Ett exempel är PostgreSQL `ON UPDATE` trigger som returnerar `NULL`. I sådana fall är det möjligt att ställa in [`django.db.models.Options.select_on_save`](/sv/6.0/ref/models/options/#django.db.models.Options.select_on_save)-flaggan för att tvinga sparandet att använda den gamla algoritmen. ### Mindre funktioner - Autentiseringsbackends kan höja `PermissionDenied` för att omedelbart misslyckas med autentiseringskedjan. - Flaggan `HttpOnly` kan ställas in på CSRF-cookien med [`CSRF_COOKIE_HTTPONLY`](/sv/6.0/ref/settings/#std-setting-CSRF_COOKIE_HTTPONLY). - `assertQuerysetEqual()` kontrollerar nu för odefinierad ordning och ger upphov till [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError) om odefinierad ordning upptäcks. Ordningen ses som odefinierad om den givna `QuerySet` inte är ordnad och det finns mer än ett ordnat värde att jämföra mot. - Lagt till [`earliest()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.earliest) för symmetri med [`latest()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.latest). - Förutom [`year`](/sv/6.0/ref/models/querysets/#std-fieldlookup-year), [`month`](/sv/6.0/ref/models/querysets/#std-fieldlookup-month) och [`day`](/sv/6.0/ref/models/querysets/#std-fieldlookup-day) stöder ORM nu även [`hour`](/sv/6.0/ref/models/querysets/#std-fieldlookup-hour), [`minute`](/sv/6.0/ref/models/querysets/#std-fieldlookup-minute) och [`second`](/sv/6.0/ref/models/querysets/#std-fieldlookup-second). - Django omsluter nu alla [**PEP 249**](https://peps.python.org/pep-0249/) undantag. - Standardwidgetarna för [`EmailField`](/sv/6.0/ref/forms/fields/#django.forms.EmailField), [`URLField`](/sv/6.0/ref/forms/fields/#django.forms.URLField), [`IntegerField`](/sv/6.0/ref/forms/fields/#django.forms.IntegerField), [`FloatField`](/sv/6.0/ref/forms/fields/#django.forms.FloatField) och [`DecimalField`](/sv/6.0/ref/forms/fields/#django.forms.DecimalField) använder de nya typattributen som finns tillgängliga i HTML5 (`type='email'`, `type='url'`, `type='number'`). Observera att på grund av oregelbundet stöd för inmatningstypen `number` med lokaliserade siffror i nuvarande webbläsare, använder Django den endast när numeriska fält inte är lokaliserade. - Argumentet `number` för [lazy plural translations](/sv/6.0/topics/i18n/translation/#lazy-plural-translations) kan anges vid översättningstidpunkten snarare än vid definitionstidpunkten. - För anpassade hanteringskommandon: Verifiering av giltiga inställningar i kommandon som begär det med hjälp av det interna alternativet `BaseCommand.can_import_settings` utförs nu oberoende av hanteringen av den lokala inställningen som ska vara aktiv när kommandot körs. Det senare kan nu påverkas av det nya interna alternativet `BaseCommand.leave_locale_alone`. Se [Hanteringskommandon och lokala språk](/sv/6.0/howto/custom-management-commands/#management-commands-and-locales) för mer information. - [`success_url`](/sv/6.0/ref/class-based-views/mixins-editing/#django.views.generic.edit.DeletionMixin.success_url) i [`DeletionMixin`](/sv/6.0/ref/class-based-views/mixins-editing/#django.views.generic.edit.DeletionMixin) interpoleras nu med dess ```objekts` ``__dict__```. - [`HttpResponseRedirect`](/sv/6.0/ref/request-response/#django.http.HttpResponseRedirect) och [`HttpResponsePermanentRedirect`](/sv/6.0/ref/request-response/#django.http.HttpResponsePermanentRedirect) tillhandahåller nu ett `url`-attribut (motsvarande URL:en som svaret kommer att omdirigeras till). - Cachebackend `MemcachedCache` använder nu det senaste [`pickle`](https://docs.python.org/3/library/pickle.html#module-pickle)-protokollet som finns tillgängligt. - Lagt till [`SuccessMessageMixin`](/sv/6.0/ref/contrib/messages/#django.contrib.messages.views.SuccessMessageMixin) som tillhandahåller ett `uccess_message`-attribut för [`FormView`](/sv/6.0/ref/class-based-views/generic-editing/#django.views.generic.edit.FormView)-baserade klasser. - Lagt till alternativen [`django.db.models.ForeignKey.db_constraint`](/sv/6.0/ref/models/fields/#django.db.models.ForeignKey.db_constraint) och [`django.db.models.ManyToManyField.db_constraint`](/sv/6.0/ref/models/fields/#django.db.models.ManyToManyField.db_constraint). - Det jQuery-bibliotek som är inbäddat i admin har uppgraderats till version 1.9.1. - Syndikeringsflöden ([`django.contrib.syndication`](/sv/6.0/ref/contrib/syndication/#module-django.contrib.syndication)) kan nu skicka extra kontext till flödesmallar med hjälp av en ny [`Feed.get_context_data()`](/sv/6.0/ref/contrib/syndication/#django.contrib.syndication.Feed.get_context_data) callback. - Kolumnerna i adminlistan har en klass `column-` i HTML så att kolumnrubriken kan stylas med CSS, t.ex. för att ange en kolumnbredd. - [isoleringsnivå](/sv/6.0/ref/databases/#database-isolation-level) kan anpassas under PostgreSQL. - Malltaggen [`blocktrans`](/sv/6.0/topics/i18n/translation/#std-templatetag-blocktrans) respekterar nu `TEMPLATE_STRING_IF_INVALID` för variabler som inte finns i sammanhanget, precis som andra mallkonstruktioner. - `SimpleLazyObject` kommer nu att presentera mer användbara representationer i felsökningssituationer i skalet. - Generic [`GeometryField`](/sv/6.0/ref/contrib/gis/model-api/#django.contrib.gis.db.models.GeometryField) är nu redigerbar med OpenLayers-widgeten i admin. - Dokumentationen innehåller en [checklista för distribution](/sv/6.0/howto/deployment/checklist/). - Kommandot [`diffsettings`](/sv/6.0/ref/django-admin/#django-admin-diffsettings) har fått ett alternativ `--all`. - `django.forms.fields.Field.__init__` anropar nu `super()`, vilket gör det möjligt för fältmixins att implementera `__init__()`-metoder som kommer att anropas på ett tillförlitligt sätt. - The `validate_max` parameter was added to `BaseFormSet` and [`formset_factory()`](/sv/6.0/ref/forms/formsets/#django.forms.formsets.formset_factory), and `ModelForm` and inline versions of the same. The behavior of validation for formsets with `max_num` was clarified. The previously undocumented behavior that hardened formsets against memory exhaustion attacks was documented, and the undocumented limit of the higher of 1000 or `max_num` forms was changed so it is always 1000 more than `max_num`. - Lagt till `BCryptSHA256PasswordHasher` för att lösa problemet med trunkering av lösenord med bcrypt. - [Pillow](https://pypi.org/project/Pillow/) är nu det föredragna bildmanipuleringsbiblioteket att använda med Django. [PIL](https://pypi.org/project/PIL/) är i väntan på utfasning (stöd kommer att tas bort i Django 1.8). För att uppgradera bör du **först** avinstallera PIL och **därefter** installera Pillow. - [`ModelForm`](/sv/6.0/topics/forms/modelforms/#django.forms.ModelForm) accepterar flera nya `Meta` alternativ. - Fält som ingår i listan `localized_fields` kommer att lokaliseras (genom att ställa in `localize` på formulärfältet). - Alternativen `labels`, `help_texts` och `error_messages` kan användas för att anpassa standardfälten, se [Åsidosätta standardfälten](/sv/6.0/topics/forms/modelforms/#modelforms-overriding-default-fields) för mer information. - Argumentet `choices` till modellfält accepterar nu en iterabel av iterabler i stället för att kräva en iterabel av listor eller tupler. - Orsaksfrasen kan anpassas i HTTP-svar med hjälp av [`reason_phrase`](/sv/6.0/ref/request-response/#django.http.HttpResponse.reason_phrase). - När du anger webbadressen till nästa sida för `django.contrib.auth.views.logout()`, `django.contrib.auth.views.password_reset()`, `django.contrib.auth.views.password_reset_confirm()` och `django.contrib.auth.views.password_change()` kan du nu ange URL-namn och de kommer att lösas upp. - Det nya alternativet [`dumpdata --pks`](/sv/6.0/ref/django-admin/#cmdoption-dumpdata-pks) anger primärnycklarna för de objekt som ska dumpas. Detta alternativ kan endast användas med en modell. - Lagt till `QuerySet` metoderna [`first()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.first) och [`last()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.last) som är bekvämlighetsmetoder som returnerar det första eller sista objektet som matchar filtren. Returnerar `None` om det inte finns några objekt som matchar. - [`View`](/sv/6.0/ref/class-based-views/base/#django.views.generic.base.View) och [`RedirectView`](/sv/6.0/ref/class-based-views/base/#django.views.generic.base.RedirectView) stöder nu HTTP-metoden `PATCH`. - `GenericForeignKey` tar nu ett valfritt `for_concrete_model` argument, som när det är inställt på `False` tillåter fältet att referera till proxy-modeller. Standardvärdet är `True` för att behålla det gamla beteendet. - Klassen:~django.middleware.locale.LocaleMiddleware lagrar nu det aktiva språket i sessionen om det inte redan finns där. Detta förhindrar förlust av språkinställningar efter sessionspolning, t.ex. utloggning. - [`SuspiciousOperation`](/sv/6.0/ref/exceptions/#django.core.exceptions.SuspiciousOperation) har delats upp i ett antal underklasser, och var och en kommer att loggas till en matchande namngiven logger under `django.security` loggningshierarkin. Tillsammans med denna förändring används en `handler400` mekanism och standardvy när en `SuspiciousOperation` når WSGI-handlaren för att returnera en `HttpResponseBadRequest`. - Undantaget [`DoesNotExist`](/sv/6.0/ref/models/class/#django.db.models.Model.DoesNotExist) innehåller nu ett meddelande som anger namnet på det attribut som används för uppslagningen. - Metoden [`get_or_create()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.get_or_create) kräver inte längre minst ett nyckelordsargument. - Klassen [`SimpleTestCase`](/sv/6.0/topics/testing/tools/#django.test.SimpleTestCase) innehåller en ny assertion-hjälpare för att testa formulärfel: `django.test.SimpleTestCase.assertFormsetError()`. - Listan över relaterade fält som läggs till i en [`QuerySet`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet) av [`select_related()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.select_related) kan rensas med `select_related(None)`. - Metoderna [`get_extra()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.InlineModelAdmin.get_extra) och [`get_max_num()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.InlineModelAdmin.get_max_num) på [`InlineModelAdmin`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.InlineModelAdmin) kan åsidosättas för att anpassa det extra och maximala antalet inline-formulär. - Formset har nu en [`total_error_count()`](/sv/6.0/topics/forms/formsets/#django.forms.formsets.BaseFormSet.total_error_count)-metod. - [`ModelForm`](/sv/6.0/topics/forms/modelforms/#django.forms.ModelForm)-fält kan nu åsidosätta felmeddelanden som definieras i modellfält genom att använda [`error_messages`](/sv/6.0/ref/forms/fields/#django.forms.Field.error_messages)-argumentet i en `Field`-konstruktör. För att dra nytta av den här nya funktionen med dina anpassade fält, [se den uppdaterade rekommendationen](/sv/6.0/ref/forms/validation/#raising-validation-error) för att skapa ett `ValidationError`. - [`ModelAdmin`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin) bevarar nu filter i listvyn efter att ett objekt har skapats, redigerats eller tagits bort. Det är möjligt att återställa det tidigare beteendet att rensa filter genom att ställa in attributet [`preserve_filters`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.preserve_filters) till `False`. - Lagt till [`FormMixin.get_prefix`](/sv/6.0/ref/class-based-views/mixins-editing/#django.views.generic.edit.FormMixin.get_prefix) (som returnerar [`FormMixin.prefix`](/sv/6.0/ref/class-based-views/mixins-editing/#django.views.generic.edit.FormMixin.prefix) som standard) för att möjliggöra anpassning av [`prefix`](/sv/6.0/ref/forms/api/#django.forms.Form.prefix) för formuläret. - Råa frågor (`Manager.raw()` eller `cursor.execute()`) kan nu använda parameterstilen ”pyformat”, där platshållare i frågan ges som `'%(name)s'` och parametrarna skickas som en ordbok snarare än en lista (utom på SQLite). Detta har länge varit möjligt (men inte officiellt stöds) på MySQL och PostgreSQL, och är nu också tillgängligt på Oracle. - Standardantalet iterationer för PBKDF2-lösenordshasher har ökats med 20%. Denna bakåtkompatibla ändring kommer inte att påverka befintliga lösenord eller användare som har underklassat `django.contrib.auth.hashers.PBKDF2PasswordHasher` för att ändra standardvärdet. Lösenord :ref:\` kommer att uppgraderas \\` för att använda det nya iterationsantalet vid behov. ## Bakåtkompatibla ändringar i 1.6 > **Warning** > > Utöver de ändringar som beskrivs i det här avsnittet bör du granska [deprecation plan](/sv/6.0/internals/deprecation/#deprecation-removed-in-1-6) 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. ### Ny modell för transaktionshantering #### Förändringar i beteendet Autocommit på databasnivå är aktiverat som standard i Django 1.6. Även om detta inte ändrar den allmänna andan i Djangos transaktionshantering, finns det några bakåtkompatibiliteter. #### Sparpunkter och `assertNumQueries` Ändringarna i transaktionshanteringen kan resultera i ytterligare uttalanden för att skapa, frigöra eller rulla tillbaka sparpunkter. Det är mer troligt att detta händer med SQLite, eftersom det inte hade stöd för sparpunkter förrän i den här versionen. Om tester som använder [`assertNumQueries()`](/sv/6.0/topics/testing/tools/#django.test.TransactionTestCase.assertNumQueries) misslyckas på grund av ett högre antal frågor än förväntat, kontrollera att de extra frågorna är relaterade till sparpunkter och justera det förväntade antalet frågor i enlighet med detta. #### Alternativ för autocommit för PostgreSQL I tidigare versioner var autocommit på databasnivå endast ett alternativ för PostgreSQL, och det inaktiverades som standard. Detta alternativ ignoreras nu och kan tas bort. ### Ny testkörare För att upprätthålla större överensstämmelse med Pythons `unittest`-modul stöder den nya testköraren (`django.test.runner.DiscoverRunner`) inte automatiskt vissa typer av tester som stöddes av den tidigare köraren: - Tester i filerna `models.py` och `tests/__init__.py` kommer inte längre att hittas och köras. Flytta dem till en fil vars namn börjar med `test`. - Doctests kommer inte längre att upptäckas automatiskt. För att integrera doctests i din testsvit, följ [rekommendationerna i Python-dokumentationen](https://docs.python.org/3/library/doctest.html#doctest-unittest-api). Django innehåller en modifierad version av [`doctest`](https://docs.python.org/3/library/doctest.html#module-doctest)-modulen från Pythons standardbibliotek (i `django.test._doctest`) och innehåller några ytterligare doctest-verktyg. Dessa verktyg är föråldrade och kommer att tas bort i Django 1.8; doctest-sviter bör uppdateras för att fungera med standardbibliotekets doctest-modul (eller konverteras till `unittest`-kompatibla tester). Om du vill fördröja uppdateringar av din testsvit kan du ställa in din [`TEST_RUNNER`](/sv/6.0/ref/settings/#std-setting-TEST_RUNNER)-inställning till `django.test.simple.DjangoTestSuiteRunner` för att helt återställa det gamla testbeteendet. `DjangoTestSuiteRunner` är föråldrad men kommer inte att tas bort från Django förrän version 1.8. ### Borttagning av `django.contrib.gis.tests.GeoDjangoTestSuiteRunner` GeoDjango anpassad testlöpare Detta är för utvecklare som arbetar med själva GeoDjango-applikationen och relaterat till punkten ovan om ändringar i testlöparna: Testlöparen `django.contrib.gis.tests.GeoDjangoTestSuiteRunner` har tagits bort och den fristående GeoDjango-testkörningsinställningen som den implementerade stöds inte längre. För att köra GeoDjango-testerna använder du helt enkelt den nya `DiscoverRunner` och anger appen `django.contrib.gis`. ### Anpassade användarmodeller i tester Införandet av den nya testköraren har också något förändrat sättet som testmodeller importeras på. Som ett resultat måste alla tester som åsidosätter `AUTH_USER_MODEL` för att testa beteende med en av Djangos testanvändarmodeller ( `django.contrib.auth.tests.custom_user.CustomUser` och `django.contrib.auth.tests.custom_user.ExtensionUser`) nu uttryckligen importera användarmodellen i din testmodul: ``` from django.contrib.auth.tests.custom_user import CustomUser @override_settings(AUTH_USER_MODEL="auth.CustomUser") class CustomUserFeatureTests(TestCase): def test_something(self): # Test code here ... ``` Denna import tvingar den anpassade användarmodellen att registreras. Utan denna import kommer testet inte att kunna byta in den anpassade användarmodellen och du kommer att få en felrapportering: ```pytb ImproperlyConfigured: AUTH_USER_MODEL refers to model 'auth.CustomUser' that has not been installed ``` ### Tidszonmedvetna uppslagningar av `dag`, `månad` och `veckodag` Django 1.6 introducerar stöd för tidszoner för [`day`](/sv/6.0/ref/models/querysets/#std-fieldlookup-day), [`month`](/sv/6.0/ref/models/querysets/#std-fieldlookup-month) och [`week_day`](/sv/6.0/ref/models/querysets/#std-fieldlookup-week_day) när [`USE_TZ`](/sv/6.0/ref/settings/#std-setting-USE_TZ) är `True`. Dessa uppslagningar utfördes tidigare i UTC oavsett aktuell tidszon. Detta kräver [tidszonsdefinitioner i databasen](/sv/6.0/ref/models/querysets/#database-time-zone-definitions). Om du använder SQLite måste du installera [pytz](http://pytz.sourceforge.net/). Om du använder MySQL måste du installera [pytz](http://pytz.sourceforge.net/) och ladda tidszontabellerna med [mysql\_tzinfo\_to\_sql](https://dev.mysql.com/doc/refman/en/mysql-tzinfo-to-sql.html). ### Tillägg av `QuerySet.datetimes()` När [time zone support](/sv/6.0/topics/i18n/timezones/) som lades till i Django 1.4 var aktivt gav [`QuerySet.dates()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.dates) oväntade resultat, eftersom aggregeringen utfördes i UTC. För att åtgärda detta introducerar Django 1.6 ett nytt API, [`QuerySet.datetimes()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.datetimes). Detta kräver några ändringar i din kod. #### `QuerySet.dates()` returnerar `datum`-objekt [`QuerySet.dates()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.dates) returnerar nu en lista med [`date`](https://docs.python.org/3/library/datetime.html#datetime.date). Den brukade returnera en lista med [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime). [`QuerySet.datetimes()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.datetimes) returnerar en lista med [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime). #### `QuerySet.dates()` inte längre användbar på `DateTimeField` [`QuerySet.dates()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.dates) ger upphov till ett fel om det används på [`DateTimeField`](/sv/6.0/ref/models/fields/#django.db.models.DateTimeField) när tidszonsstöd är aktivt. Använd [`QuerySet.datetimes()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.datetimes) istället. #### `date_hierarchy` kräver definitioner av tidszoner Funktionen [`date_hierarchy`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.date_hierarchy) i admin förlitar sig nu på [`QuerySet.datetimes()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.datetimes) när den används på en [`DateTimeField`](/sv/6.0/ref/models/fields/#django.db.models.DateTimeField). Detta kräver tidszonsdefinitioner i databasen när [`USE_TZ`](/sv/6.0/ref/settings/#std-setting-USE_TZ) är `True`. [Learn more](/sv/6.0/ref/models/querysets/#database-time-zone-definitions). #### `date_list` i generiska vyer kräver tidszonsdefinitioner Av samma anledning kräver åtkomst till `date_list` i samband med en datumbaserad generisk vy tidszonsdefinitioner i databasen när vyn är baserad på en [`DateTimeField`](/sv/6.0/ref/models/fields/#django.db.models.DateTimeField) och [`USE_TZ`](/sv/6.0/ref/settings/#std-setting-USE_TZ) är `True`. [Learn more](/sv/6.0/ref/models/querysets/#database-time-zone-definitions). ### Nya uppslagsord kan krocka med modellfält Django 1.6 introducerar `hour`, `minute` och `second` lookups på [`DateTimeField`](/sv/6.0/ref/models/fields/#django.db.models.DateTimeField). Om du hade modellfält som heter `hour`, `minute` eller `second` kommer de nya uppslagningarna att krocka med dina fältnamn. Lägg till en explicit [`exact`](/sv/6.0/ref/models/querysets/#std-fieldlookup-exact) lookup om detta är ett problem. ### `BooleanField` har inte längre `False` som standard När en [`BooleanField`](/sv/6.0/ref/models/fields/#django.db.models.BooleanField) inte har en explicit [`default`](/sv/6.0/ref/models/fields/#django.db.models.Field.default), är det implicita standardvärdet `None`. I tidigare versioner av Django var det `False`, men det representerade inte exakt avsaknaden av ett värde. Kod som förlitar sig på att standardvärdet är `False` kan ge upphov till ett undantag när nya modellinstanser sparas i databasen, eftersom `None` inte är ett acceptabelt värde för en [`BooleanField`](/sv/6.0/ref/models/fields/#django.db.models.BooleanField). Du bör antingen ange `default=False` i fältdefinitionen eller se till att fältet är inställt på `True` eller `False` innan du sparar objektet. ### Översättningar och kommentarer i mallar #### Extrahering av översättningar efter kommentarer Extrahering av översättningsbara bokstäver från mallar med kommandot [`makemessages`](/sv/6.0/ref/django-admin/#django-admin-makemessages) upptäcker nu korrekt i18n-konstruktioner när de finns efter en kommentar av typen `{#` / `#}` på samma rad. T.ex: ```html+django {# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %} ``` #### Plats för översättarens kommentarer [Kommentarer för översättare i mallar](/sv/6.0/topics/i18n/translation/#translator-comments-in-templates) som anges med `{#` / `#}` måste vara i slutet av en rad. Om de inte gör det ignoreras kommentarerna och [`makemessages`](/sv/6.0/ref/django-admin/#django-admin-makemessages) genererar en varning. Ett exempel: ```html+django {# Translators: This is ignored #}{% trans "Translate me" %} {{ title }}{# Translators: Extracted and associated with 'Welcome' below #}

{% trans "Welcome" %}

``` ### Citat i `reverse()` Vid omvända webbadresser tillämpade Django inte `django.utils.http.urlquote` på argument innan de interpolerades i URL-mönster. Denna bugg är åtgärdad i Django 1.6. Om du arbetade runt denna bugg genom att tillämpa URL-citering innan du skickar argument till `reverse()`, kan detta resultera i dubbelcitering. Om detta händer, ta helt enkelt bort URL-citeringen från din kod. Du kommer också att behöva ersätta specialtecken i URL:er som används i [`assertRedirects()`](/sv/6.0/topics/testing/tools/#django.test.SimpleTestCase.assertRedirects) med deras kodade versioner. ### Lagring av IP-adresser i kommentarsappen Kommentarsappen använder nu ett `GenericIPAddressField` för att lagra kommentatorernas IP-adresser, för att stödja kommentarer som skickas från IPv6-adresser. Hittills har de lagrats i en ”IPAddressField”, som endast är avsedd att stödja IPv4. När du sparar en kommentar från en IPv6-adress skulle adressen trunkeras i tysthet i MySQL-databaser och ge upphov till ett undantag i Oracle. Du måste ändra kolumntypen i din databas för att dra nytta av den här ändringen. För MySQL kör du den här frågan på projektets databas: ```sql ALTER TABLE django_comments MODIFY ip_address VARCHAR(39); ``` För Oracle, kör den här frågan: ```sql ALTER TABLE DJANGO_COMMENTS MODIFY (ip_address VARCHAR2(39)); ``` Om du inte tillämpar den här ändringen är beteendet oförändrat: på MySQL trunkeras IPv6-adresser tyst; på Oracle genereras ett undantag. Ingen databasändring behövs för SQLite- eller PostgreSQL-databaser. ### Procentenheter i `cursor.execute`-frågor När du kör råa SQL-frågor genom metoden [cursor.execute](/sv/6.0/topics/db/sql/#executing-custom-sql) har regeln om att dubbla procentlitteraler (`%`) inuti frågan förenhetligats. Tidigare berodde beteendet på databasens backend. Nu, i alla backends, behöver du bara dubbla bokstavliga procenttecken om du också tillhandahåller ersättningsparametrar. Till exempel: ``` # No parameters, no percent doubling cursor.execute("SELECT foo FROM bar WHERE baz = '30%'") # Parameters passed, non-placeholders have to be doubled cursor.execute("SELECT foo FROM bar WHERE baz = '30%%' and id = %s", [self.id]) ``` `SQLite`-användare måste kontrollera och uppdatera sådana frågor. ### Hjälptext för modellformulärsfält för ManyToManyField-fält HTML rendering of model form fields corresponding to [`ManyToManyField`](/sv/6.0/ref/models/fields/#django.db.models.ManyToManyField) model fields used to get the hardcoded sentence: > *Håll ned ”Control”, eller ”Command” på en Mac, för att välja mer än en.* (eller dess översättning till den aktiva språkdräkten) införs som den hjälptext som visas längs dem om varken attributen [`model`](/sv/6.0/ref/models/fields/#django.db.models.Field.help_text) eller [`form`](/sv/6.0/ref/forms/fields/#django.forms.Field.help_text) `help_text` specificerades av användaren (eller om denna sträng bifogades till någon `help_text` som tillhandahölls). Eftersom detta skedde på modellagret fanns det inget sätt att förhindra att texten visades i fall där den inte var tillämplig, t.ex. formulärfält som implementerar användarinteraktioner som inte involverar ett tangentbord och/eller en mus. Från och med Django 1.6, som en tillfällig bestämmelse om bakåtkompatibilitet, har logiken för att lägga till meningen ”Håll ner…” flyttats till fältlagret för modellformulär och ändrats för att lägga till texten endast när den associerade widgeten är [`SelectMultiple`](/sv/6.0/ref/forms/widgets/#django.forms.SelectMultiple) eller valda underklasser. The change can affect you in a backward incompatible way if you employ custom model form fields and/or widgets for `ManyToManyField` model fields whose UIs do rely on the automatic provision of the mentioned hardcoded sentence. These form field implementations need to adapt to the new scenario by providing their own handling of the `help_text` attribute. Program som använder Django [model form](/sv/6.0/topics/forms/modelforms/) faciliteter tillsammans med Django inbyggda formulär [fields](/sv/6.0/ref/forms/fields/) och [widgets](/sv/6.0/ref/forms/widgets/) påverkas inte men måste vara medvetna om vad som beskrivs i [Ändring av hjälptexten för modellformulärsfält för ManyToManyField-fält](#m2m-help-text-deprecation) nedan. ### QuerySet iteration `QuerySet`-iterationen ändrades så att alla hämtade rader omedelbart konverterades till `Model`-objekt. I Django 1.5 och tidigare konverterades de hämtade raderna till `Model`-objekt i bitar om 100. Befintlig kod kommer att fungera, men antalet rader som konverteras till objekt kan ändras i vissa användningsfall. Sådana användningar inkluderar delvis loopning över en frågeuppsättning eller all användning som slutar med att göra `__bool__` eller `__contains__`. I synnerhet hämtade de flesta databasbackends alla rader på en gång redan i 1.5. It is still possible to convert the fetched rows to `Model` objects lazily by using the [`iterator()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.iterator) method. ### [`BoundField.label_tag`](/sv/6.0/ref/forms/api/#django.forms.BoundField.label_tag) inkluderar nu formulärets [`label_suffix`](/sv/6.0/ref/forms/api/#django.forms.Form.label_suffix) Detta överensstämmer med hur metoder som [`Form.as_p`](/sv/6.0/ref/forms/api/#django.forms.Form.as_p) och [`Form.as_ul`](/sv/6.0/ref/forms/api/#django.forms.Form.as_ul) återger etiketter. Om du manuellt renderar `label_tag` i dina mallar: ```html+django {{ form.my_field.label_tag }}: {{ form.my_field }} ``` vill du ta bort kolon (eller vilken annan separator du än använder) för att undvika att duplicera den när du uppgraderar till Django 1.6. Följande mall i Django 1.6 kommer att återges identiskt med ovanstående mall i Django 1.5, förutom att kolon kommer att visas inuti elementet `