QuerySetLink to this heading#Detta dokument beskriver detaljerna i API:et QuerySet. Det bygger på det material som presenteras i guiderna model och database query, så du vill förmodligen läsa och förstå dessa dokument innan du läser det här.
I den här referensen använder vi exempel på bloggmodeller som presenteras i guide för databasfrågor.
\nQuerySet utvärderasLink to this heading#Internt kan en QuerySet konstrueras, filtreras, skivas och i allmänhet skickas runt utan att faktiskt träffa databasen. Ingen databasaktivitet sker faktiskt förrän du gör något för att utvärdera queryset.
Du kan utvärdera en QuerySet på följande sätt:
**En QuerySet är itererbar och den utför sin databasfråga första gången du itererar över den. Till exempel: kommer detta att skriva ut rubriken på alla poster i databasen:
for e in Entry.objects.all():\n print(e.headline)\nObservera: Använd inte detta om allt du vill göra är att avgöra om minst ett resultat finns. Det är mer effektivt att använda exists().
**En QuerySet kan också itereras över med hjälp av async for:
async for e in Entry.objects.all():\n results.append(e)\nBåde synkrona och asynkrona iteratorer av QuerySets delar samma underliggande cache.
\n**Som förklaras i Begränsning av QuerySet, kan en QuerySet skivas med hjälp av Pythons syntax för array-skivning. Att skiva en ovärderad QuerySet returnerar vanligtvis en annan ovärderad QuerySet, men Django kommer att utföra databasförfrågan om du använder parametern ”step” i slice-syntaxen och returnerar en lista. Att skära en QuerySet som har utvärderats returnerar också en lista.
Observera också att även om slicing av en ovärderad QuerySet returnerar en annan ovärderad QuerySet, är det inte tillåtet att modifiera den ytterligare (t.ex. lägga till fler filter eller ändra ordningen), eftersom det inte översätts bra till SQL och det skulle inte heller ha en tydlig mening.
Pickling/Caching. Se följande avsnitt för detaljer om vad som gäller vid ”picking” av QuerySets. Det viktiga i det här avsnittet är att resultaten läses från databasen.
repr(). En QuerySet utvärderas när du anropar repr(). på den. Detta är för enkelhetens skull i Pythons interaktiva tolk, så att du omedelbart kan se dina resultat när du använder API:et interaktivt.
len(). En QuerySet utvärderas när du anropar len() på den. Detta returnerar, som du kanske förväntar dig, längden på resultatlistan.
Obs: Om du bara behöver bestämma antalet poster i uppsättningen (och inte behöver de faktiska objekten) är det mycket effektivare att hantera en räkning på databasnivå med SQL: s ``SELECT COUNT(*) ``. Django tillhandahåller en count()-metod av just denna anledning.
list(). Tvinga fram utvärdering av en QuerySet genom att anropa list(). på den. Till exempel:
entry_list = list(Entry.objects.all())\nbool(). Om en QuerySet testas i ett booleskt sammanhang, t.ex. med bool()., or, and eller en if-sats, kommer frågan att utföras. Om det finns minst ett resultat är QuerySet True, annars False. Till exempel:
if Entry.objects.filter(headline="Test"):\n print("There is at least one Entry with the headline Test")\nObservera: Om du bara vill avgöra om minst ett resultat finns (och inte behöver de faktiska objekten) är det effektivare att använda exists().
Om du pickle en QuerySet, kommer detta att tvinga alla resultat att laddas in i minnet före pickling. Pickling används vanligtvis som en föregångare till cachelagring och när det cachade querysetet laddas om vill du att resultaten redan ska finnas och vara redo att användas (att läsa från databasen kan ta lite tid, vilket motverkar syftet med cachelagring). Detta innebär att när du plockar upp en QuerySet innehåller den resultaten vid den tidpunkt då den plockades upp, snarare än de resultat som för närvarande finns i databasen.
Om du bara vill plocka ut den information som behövs för att återskapa QuerySet från databasen vid ett senare tillfälle, plockar du ut query-attributet för QuerySet. Du kan sedan återskapa den ursprungliga QuerySet (utan några resultat laddade) med hjälp av någon kod som denna:
>>> import pickle\n>>> query = pickle.loads(s) # Assuming 's' is the pickled string.\n>>> qs = MyModel.objects.all()\n>>> qs.query = query # Restore the original 'query'.\nAttributet query är ett opakt objekt. Det representerar det interna i query-konstruktionen och är inte en del av det publika API:et. Det är dock säkert (och stöds fullt ut) att plocka ut och plocka in attributets innehåll enligt beskrivningen här.
Här är den formella deklarationen av en QuerySet:
Vanligtvis när du interagerar med en QuerySet använder du den genom att kedja filter. För att få detta att fungera returnerar de flesta QuerySet-metoder nya querysets. Dessa metoder behandlas i detalj senare i detta avsnitt.
Klassen QuerySet har följande publika attribut som du kan använda för introspektion:
True om QuerySet är sorterad – det vill säga har en order_by()-sats eller en standardsortering på modellen. Annars False.
Returnerar True om QuerySet är sorterad och sorteringen är deterministisk. Detta kräver att sorteringen omfattar ett fält (eller en uppsättning fält) som är unikt och inte kan vara null.
För frågor som innehåller en GROUP BY-sats ignoreras modellens standardsortering. Sortering som anges med .extra(order_by=...) ignoreras också.
Den databas som kommer att användas om den här frågan körs nu.
\nQuerySetLink to this heading#Django tillhandahåller en rad förfiningsmetoder för QuerySet som ändrar antingen de typer av resultat som returneras av QuerySet eller hur dess SQL-fråga exekveras.
filter()Link to this heading#Returnerar en ny QuerySet som innehåller objekt som matchar de angivna uppslagningsparametrarna.
Uppslagsparametrarna (**kwargs) ska vara i det format som beskrivs i Fältuppslag nedan. Flera parametrar sammanfogas via AND i den underliggande SQL-satsen.
Om du behöver utföra mer komplexa frågor (till exempel frågor med OR-satser) kan du använda objekt av typen Q() (*args).
exkludera()Link to this heading#Returnerar en ny QuerySet som innehåller objekt som inte matchar de angivna uppslagningsparametrarna.
Uppslagsparametrarna (**kwargs) bör vara i det format som beskrivs i Field lookups nedan. Flera parametrar sammanfogas via AND i den underliggande SQL-satsen, och det hela omsluts av en NOT().
Detta exempel utesluter alla poster vars pub_date är senare än 2005-1-3 OCH vars headline är ”Hello”:
Entry.objects.exclude(pub_date__gt=datetime.date(2005, 1, 3), headline="Hello")\nI SQL-termer utvärderas detta till:
\nSELECT ...\nWHERE NOT (pub_date > '2005-1-3' AND headline = 'Hello')\nDetta exempel utesluter alla poster vars pub_date är senare än 2005-1-3 ELLER vars rubrik är ”Hello”:
Entry.objects.exclude(pub_date__gt=datetime.date(2005, 1, 3)).exclude(headline="Hello")\nI SQL-termer utvärderas detta till:
\nSELECT ...\nWHERE NOT pub_date > '2005-1-3'\nAND NOT headline = 'Hello'\nObservera att det andra exemplet är mer restriktivt.
\nOm du behöver köra mer komplexa frågor (t.ex. frågor med OR-satser) kan du använda Q objects (*args).
annotate()Link to this heading#Annoterar varje objekt i QuerySet med den angivna listan av frågeuttryck eller objekt av typen Q(). Varje objekt kan annoteras med:
ett enkelt värde, via Value();
en referens till ett fält i modellen (eller eventuella relaterade modeller), via F();
en boolean, via Q(); eller
ett resultat från ett aggregerat uttryck (medelvärden, summor etc.) beräknat över de objekt som är relaterade till objekten i QuerySet.
Varje argument till annotate() är en annotering som kommer att läggas till varje objekt i den QuerySet som returneras.
De aggregeringsfunktioner som tillhandahålls av Django beskrivs i Aggregeringsfunktioner nedan.
\nAnnoteringar som anges med nyckelordsargument kommer att använda nyckelordet som alias för annoteringen. För anonyma argument genereras ett alias baserat på namnet på aggregeringsfunktionen och det modellfält som aggregeras. Endast aggregatuttryck som refererar till ett enda fält kan vara anonyma argument. Allt annat måste vara ett nyckelordsargument.
\nOm du t.ex. manipulerar en lista med bloggar kanske du vill avgöra hur många inlägg som har gjorts i varje blogg:
\n>>> from django.db.models import Count\n>>> q = Blog.objects.annotate(Count("entry"))\n# The name of the first blog\n>>> q[0].name\n'Blogasaurus'\n# The number of entries on the first blog\n>>> q[0].entry__count\n42\nModellen Blog definierar inte ett entry__count-attribut i sig, men genom att använda ett nyckelordsargument för att ange den aggregerade funktionen kan du styra namnet på annotationen:
>>> q = Blog.objects.annotate(number_of_entries=Count("entry"))\n# The number of entries on the first blog, using the name provided\n>>> q[0].number_of_entries\n42\nFör en djupgående diskussion om aggregering, se the topic guide on Aggregation.
\nalias()Link to this heading#Samma som annotate(), men istället för att annotera objekt i QuerySet, sparas uttrycket för senare återanvändning med andra QuerySet-metoder. Detta är användbart när resultatet av själva uttrycket inte behövs, men det används för filtrering, ordning eller som en del av ett komplext uttryck. Genom att inte välja det oanvända värdet tas överflödigt arbete bort från databasen, vilket bör leda till bättre prestanda.
Om du t.ex. vill hitta bloggar med fler än 5 inlägg, men inte är intresserad av det exakta antalet inlägg, kan du göra så här:
\n>>> from django.db.models import Count\n>>> blogs = Blog.objects.alias(entries=Count("entry")).filter(entries__gt=5)\nalias() kan användas tillsammans med annotate(), exclude(), filter(), order_by() och update(). Om du vill använda ett aliaserat uttryck med andra metoder (t.ex. aggregate()) måste du uppgradera det till en annotering:
Blog.objects.alias(entries=Count("entry")).annotate(\n entries=F("entries"),\n).aggregate(Sum("entries"))\nfilter() och order_by() kan ta uttryck direkt, men konstruktion och användning av uttryck sker ofta inte på samma plats (till exempel skapar en QuerySet-metod uttryck för senare användning i vyer). alias() gör det möjligt att bygga komplexa uttryck stegvis (eventuellt över flera metoder och moduler), hänvisa till uttrycksdelarna med deras alias och använda annotate() först för slutresultatet.
order_by()Link to this heading#Som standard ordnas de resultat som returneras av en QuerySet enligt den ordningstupel som anges av alternativet ordering i modellens Meta. Du kan åsidosätta detta per QuerySet genom att använda metoden order_by.
Exempel:
\nEntry.objects.filter(pub_date__year=2005).order_by("-pub_date", "headline")\nResultatet ovan kommer att sorteras efter pub_date i fallande ordning, sedan efter headline i stigande ordning. Det negativa tecknet framför "-pub_date" anger nedstigande ordning. Stigande ordning är underförstådd. För slumpmässig ordning, använd "?", så här:
Entry.objects.order_by("?")\nObs: order_by('?')-frågor kan vara dyra och långsamma, beroende på vilken databasbackend du använder.
Om du vill beställa efter ett fält i en annan modell använder du samma syntax som när du ställer frågor över modellrelationer. Det vill säga fältets namn, följt av ett dubbelt understreck (__), följt av fältets namn i den nya modellen, och så vidare för så många modeller som du vill koppla samman. Till exempel:
Entry.objects.order_by("blog__name", "headline")\nOm du försöker beställa efter ett fält som är en relation till en annan modell, kommer Django att använda standardbeställningen på den relaterade modellen, eller beställa efter den relaterade modellens primärnyckel om det inte finns någon Meta.ordering angiven. Till exempel:, eftersom modellen Blog inte har någon standardordning angiven:
Entry.objects.order_by("blog")\n…är identisk med:
\nEntry.objects.order_by("blog__id")\nOm Blog hade ordering = ['name'], så skulle den första frågeuppsättningen vara identisk med:
Entry.objects.order_by("blog__name")\nDu kan också sortera efter query expressions genom att anropa asc() eller desc() på uttrycket:
Entry.objects.order_by(Coalesce("summary", "headline").desc())\nasc() och desc() har argument (nulls_first och nulls_last) som styr hur nollvärden sorteras.
Var försiktig när du sorterar efter fält i relaterade modeller om du också använder distinct(). Se anmärkningen i distinct() för en förklaring av hur sortering av relaterade modeller kan ändra de förväntade resultaten.
Det finns inget sätt att ange om beställningen ska vara skiftlägeskänslig. Med avseende på skiftlägeskänslighet kommer Django att ordna resultaten på det sätt som din databas backend normalt ordnar dem.
\nDu kan beställa efter ett fält som konverterats till små bokstäver med Lower som kommer att uppnå skiftlägeskonsekvent beställning:
Entry.objects.order_by(Lower("headline").desc())\nOm du inte vill att någon sortering ska tillämpas på en fråga, inte ens standardsorteringen, anropar du order_by() utan parametrar.
Du kan se om en fråga är ordnad eller inte genom att kontrollera attributet QuerySet.ordered, som blir True om QuerySet har ordnats på något sätt.
Varje anrop av order_by() rensar bort alla tidigare ordningar. Till exempel: kommer den här frågan att sorteras efter pub_date och inte headline:
Entry.objects.order_by("headline").order_by("pub_date")\nreverse()Link to this heading#Använd metoden reverse() för att vända den ordning i vilken elementen i en queryset returneras. Om du anropar reverse() en andra gång återställs ordningen till den normala riktningen.
Om du vill hämta de ”sista” fem objekten i en frågeuppsättning kan du göra så här:
\nmy_queryset.reverse()[:5]\nObservera att detta inte är riktigt samma sak som att skära från slutet av en sekvens i Python. Exemplet ovan returnerar det sista objektet först, sedan det näst sista objektet och så vidare. Om vi hade en Python-sekvens och tittade på seq[-5:], skulle vi se det femte sista objektet först. Django stöder inte detta sätt (att skära från slutet), eftersom det inte är möjligt att göra det effektivt i SQL.
Observera även att reverse() normalt endast bör anropas för en QuerySet med definierad sortering (t.ex. vid frågor mot en modell som definierar en standardsortering, eller när order_by() används). Om ingen sådan sortering har definierats för en viss QuerySet har anrop till reverse() ingen verklig effekt (sorteringen var odefinierad innan reverse() anropades och förblir odefinierad efteråt).
distinct()Link to this heading#Returnerar en ny QuerySet som använder SELECT DISTINCT i sin SQL-fråga. Detta eliminerar duplicerade rader från frågeresultaten.
Som standard kommer en QuerySet inte att eliminera duplicerade rader. I praktiken är detta sällan ett problem, eftersom enkla frågor som Blog.objects.all() inte introducerar möjligheten till duplicerade resultatrader. Men om din fråga spänner över flera tabeller är det möjligt att få dubbla resultat när en QuerySet utvärderas. Det är då du skulle använda distinct().
Endast på PostgreSQL kan du skicka positionella argument (`` * fält``) för att ange namnen på fält som `` DISTINCT`` ska gälla. Detta översätts till en SQL-fråga SELECT DISTINCT ON. Här är skillnaden. Vid ett normalt distinct()-anrop jämför databasen varje fält i varje rad när den avgör vilka rader som är distinkta. Vid ett distinct()-anrop med specificerade fältnamn jämför databasen bara de specificerade fältnamnen.
Exempel (de efter den första kommer bara att fungera på PostgreSQL):
\n>>> Author.objects.distinct()\n<QuerySet [...]>\n>>> Entry.objects.order_by("pub_date").distinct("pub_date")\n<QuerySet [...]>\n>>> Entry.objects.order_by("blog").distinct("blog")\n<QuerySet [...]>\n>>> Entry.objects.order_by("author", "pub_date").distinct("author", "pub_date")\n<QuerySet [...]>\n>>> Entry.objects.order_by("blog__name", "mod_date").distinct("blog__name", "mod_date")\n<QuerySet [...]>\n>>> Entry.objects.order_by("author", "pub_date").distinct("author")\n<QuerySet [...]>\nvärden()Link to this heading#Returnerar en QuerySet som returnerar ordböcker, snarare än modellinstanser, när den används som en iterabel.
Var och en av dessa ordböcker representerar ett objekt, med nycklar som motsvarar attributnamnen för modellobjekt.
\nI detta exempel jämförs ordlistorna i values() med de normala modellobjekten:
# This list contains a Blog object.\n>>> Blog.objects.filter(name__startswith="Beatles")\n<QuerySet [<Blog: Beatles Blog>]>\n\n# This list contains a dictionary.\n>>> Blog.objects.filter(name__startswith="Beatles").values()\n<QuerySet [{'id': 1, 'name': 'Beatles Blog', 'tagline': 'All the latest Beatles news.'}]>\nMetoden values() tar emot valfria positionella argument, *fields, som anger fältnamn som SELECT ska begränsas till. Om du anger fälten kommer varje dictionary endast att innehålla fältnycklarna/värdena för de fält du anger. Om du inte anger fälten kommer varje ordbok att innehålla en nyckel och ett värde för varje fält i databastabellen.
Exempel:
\n>>> Blog.objects.values()\n<QuerySet [{'id': 1, 'name': 'Beatles Blog', 'tagline': 'All the latest Beatles news.'}]>\n>>> Blog.objects.values("id", "name")\n<QuerySet [{'id': 1, 'name': 'Beatles Blog'}]>\nMetoden values() tar också valfria nyckelordsargument, **expressions, som skickas vidare till annotate():
>>> from django.db.models.functions import Lower\n>>> Blog.objects.values(lower_name=Lower("name"))\n<QuerySet [{'lower_name': 'beatles blog'}]>\nDu kan använda inbyggda och custom lookups i beställningen. Till exempel:
\n>>> from django.db.models import CharField\n>>> from django.db.models.functions import Lower\n>>> CharField.register_lookup(Lower)\n>>> Blog.objects.values("name__lower")\n<QuerySet [{'name__lower': 'beatles blog'}]>\nEtt aggregat inom en values()-sats tillämpas före andra argument inom samma values()-sats. Om du behöver gruppera efter ett annat värde lägger du till det i en tidigare values()-sats istället. Ett exempel:
>>> from django.db.models import Count\n>>> Blog.objects.values("entry__authors", entries=Count("entry"))\n<QuerySet [{'entry__authors': 1, 'entries': 20}, {'entry__authors': 1, 'entries': 13}]>\n>>> Blog.objects.values("entry__authors").annotate(entries=Count("entry"))\n<QuerySet [{'entry__authors': 1, 'entries': 33}]>\nNågra finesser som är värda att nämna:
\nOm du har ett fält som heter foo som är en ForeignKey, kommer standardanropet values() att returnera en ordboksnyckel som heter foo_id, eftersom detta är namnet på det dolda modellattributet som lagrar det faktiska värdet (attributet foo hänvisar till den relaterade modellen). När du anropar values() och skickar in fältnamn kan du skicka in antingen foo eller foo_id och du kommer att få tillbaka samma sak (ordboksnyckeln matchar fältnamnet du skickade in).
Till exempel:
\n>>> Entry.objects.values()\n<QuerySet [{'blog_id': 1, 'headline': 'First Entry', ...}, ...]>\n\n>>> Entry.objects.values("blog")\n<QuerySet [{'blog': 1}, ...]>\n\n>>> Entry.objects.values("blog_id")\n<QuerySet [{'blog_id': 1}, ...]>\nNär values() används tillsammans med distinct() bör du tänka på att sorteringen kan påverka resultaten. Mer information finns i anmärkningen om distinct().
Om du använder en values()-sats efter ett extra()-anrop måste alla fält som definieras av ett select-argument i extra() uttryckligen tas med i values()-anropet. Alla extra()-anrop som görs efter ett values()-anrop får sina extra valda fält ignorerade.
Det är meningslöst att anropa only() och defer() efter values(), så om du gör det utlöses ett TypeError.
För att kombinera transformationer och aggregat krävs att två annotate()-anrop används, antingen explicit eller som nyckelordsargument till values(). Som ovan, om transformationen har registrerats på den relevanta fälttypen kan den första annotate() utelämnas, vilket innebär att följande exempel är likvärdiga:
>>> from django.db.models import CharField, Count\n>>> from django.db.models.functions import Lower\n>>> CharField.register_lookup(Lower)\n>>> Blog.objects.values("entry__authors__name__lower").annotate(entries=Count("entry"))\n<QuerySet [{'entry__authors__name__lower': 'test author', 'entries': 33}]>\n>>> Blog.objects.values(entry__authors__name__lower=Lower("entry__authors__name")).annotate(\n... entries=Count("entry")\n... )\n<QuerySet [{'entry__authors__name__lower': 'test author', 'entries': 33}]>\n>>> Blog.objects.annotate(entry__authors__name__lower=Lower("entry__authors__name")).values(\n... "entry__authors__name__lower"\n... ).annotate(entries=Count("entry"))\n<QuerySet [{'entry__authors__name__lower': 'test author', 'entries': 33}]>\nDet är användbart när du vet att du bara kommer att behöva värden från ett litet antal av de tillgängliga fälten och du inte behöver funktionaliteten hos ett modellinstansobjekt. Det är mer effektivt att bara välja de fält som du behöver använda.
\nSlutligen, notera att du kan anropa filter(), order_by(), etc. efter values()-anropet, vilket innebär att dessa två anrop är identiska:
Blog.objects.values().order_by("id")\nBlog.objects.order_by("id").values()\nDe som skapade Django föredrar att lägga alla SQL-påverkande metoder först, följt (eventuellt) av alla output-påverkande metoder (som values()), men det spelar egentligen ingen roll. Det här är din chans att verkligen visa upp din individualism.
Du kan också hänvisa till fält i relaterade modeller med omvända relationer genom attributen OneToOneField, ForeignKey och ManyToManyField:
>>> Blog.objects.values("name", "entry__headline")\n<QuerySet [{'name': 'My blog', 'entry__headline': 'An entry'},\n {'name': 'My blog', 'entry__headline': 'Another entry'}, ...]>\nvalues_list()Link to this heading#Detta liknar values() förutom att den istället för att returnera ordböcker returnerar tuplar när den itereras över. Varje tupel innehåller värdet från respektive fält eller uttryck som skickas till anropet values_list() - så det första objektet är det första fältet, etc. Till exempel:
>>> Entry.objects.values_list("id", "headline")\n<QuerySet [(1, 'First entry'), ...]>\n>>> from django.db.models.functions import Lower\n>>> Entry.objects.values_list("id", Lower("headline"))\n<QuerySet [(1, 'first entry'), ...]>\nOm du bara skickar in ett enda fält kan du också skicka in parametern flat. Om den är True innebär detta att de returnerade resultaten är enskilda värden snarare än 1-tupler. Ett exempel bör göra skillnaden tydligare:
>>> Entry.objects.values_list("id").order_by("id")\n<QuerySet[(1,), (2,), (3,), ...]>\n\n>>> Entry.objects.values_list("id", flat=True).order_by("id")\n<QuerySet [1, 2, 3, ...]>\nDet är fel att skicka in flat när det finns mer än ett fält.
Du kan ange named=True för att få resultat som en namedtuple():
>>> Entry.objects.values_list("id", "headline", named=True)\n<QuerySet [Row(id=1, headline='First entry'), ...]>\nAtt använda en namngiven tupel kan göra det lättare att läsa resultaten, på bekostnad av en liten prestandaförlust för att omvandla resultaten till en namngiven tupel.
\nOm du inte skickar några värden till values_list() returneras alla fält i modellen i den ordning de deklarerades.
Ett vanligt behov är att få ett specifikt fältvärde för en viss modellinstans. För att uppnå det använder du values_list() följt av ett get()-anrop:
>>> Entry.objects.values_list("headline", flat=True).get(pk=1)\n'First entry'\nvalues() och values_list() är båda avsedda som optimeringar för ett specifikt användningsfall: att hämta en delmängd av data utan att skapa en modellinstans. Denna metafor faller sönder när man hanterar många-till-många och andra flervärdesrelationer (t.ex. en-till-många-relationen för en omvänd främmande nyckel) eftersom antagandet ”en rad, ett objekt” inte håller.
Lägg till exempel märke till beteendet vid en fråga över en ManyToManyField:
>>> Author.objects.values_list("name", "entry__headline")\n<QuerySet [('Noam Chomsky', 'Impressions of Gaza'),\n ('George Orwell', 'Why Socialists Do Not Believe in Fun'),\n ('George Orwell', 'In Defence of English Cooking'),\n ('Don Quixote', None)]>\nFörfattare med flera poster visas flera gånger och författare utan några poster har None för postrubriken.
På samma sätt visas None för poster som inte har någon författare när du frågar efter en omvänd främmande nyckel:
>>> Entry.objects.values_list("authors")\n<QuerySet [('Noam Chomsky',), ('George Orwell',), (None,)]>\ndates()Link to this heading#Returnerar en QuerySet som utvärderas till en lista med datetime.date-objekt som representerar alla tillgängliga datum av en viss typ inom innehållet i QuerySet.
field ska vara namnet på en DateField av din modell. kind bör vara antingen "year", "month", "week" eller "day". Varje datetime.date-objekt i resultatlistan ”trunkeras” till den angivna typen.
"year" returnerar en lista med alla distinkta årsvärden för fältet.
"month" returnerar en lista med alla distinkta år/månad-värden för fältet.
"week" returnerar en lista med alla distinkta år/veckovärden för fältet. Alla datum kommer att vara en måndag.
"day" returnerar en lista med alla distinkta år/månad/dag-värden för fältet.
order, som har standardvärdet 'ASC', bör vara antingen 'ASC' eller 'DESC'. Detta anger hur resultaten ska ordnas.
Exempel:
\n>>> Entry.objects.dates("pub_date", "year")\n[datetime.date(2005, 1, 1)]\n>>> Entry.objects.dates("pub_date", "month")\n[datetime.date(2005, 2, 1), datetime.date(2005, 3, 1)]\n>>> Entry.objects.dates("pub_date", "week")\n[datetime.date(2005, 2, 14), datetime.date(2005, 3, 14)]\n>>> Entry.objects.dates("pub_date", "day")\n[datetime.date(2005, 2, 20), datetime.date(2005, 3, 20)]\n>>> Entry.objects.dates("pub_date", "day", order="DESC")\n[datetime.date(2005, 3, 20), datetime.date(2005, 2, 20)]\n>>> Entry.objects.filter(headline__contains="Lennon").dates("pub_date", "day")\n[datetime.date(2005, 3, 20)]\ndatetimes()Link to this heading#Returnerar en QuerySet som utvärderas till en lista med datetime.datetime-objekt som representerar alla tillgängliga datum av en viss typ inom innehållet i QuerySet.
field_name ska vara namnet på en DateTimeField i din modell.
kind bör vara antingen "year", "month", "week", "day", "hour", "minute" eller "second". Varje datetime.datetime-objekt i resultatlistan ”trunkeras” till den angivna typen.
order, som har standardvärdet 'ASC', bör vara antingen 'ASC' eller 'DESC'. Detta anger hur resultaten ska ordnas.
tzinfo definierar den tidszon till vilken datatider konverteras före trunkering. En given datatid har faktiskt olika representationer beroende på vilken tidszon som används. Denna parameter måste vara ett datetime.tzinfo-objekt. Om den är None använder Django aktuell tidszon. Det har ingen effekt när USE_TZ är False.
none()Link to this heading#Om du anropar none() skapas en queryset som aldrig returnerar några objekt och ingen query kommer att köras vid åtkomst till resultaten. En qs.none() queryset är en instans av EmptyQuerySet.
Exempel:
\n>>> Entry.objects.none()\n<QuerySet []>\n>>> from django.db.models.query import EmptyQuerySet\n>>> isinstance(Entry.objects.none(), EmptyQuerySet)\nTrue\nall()Link to this heading#Returnerar en kopia av den aktuella QuerySet (eller QuerySet-underklassen). Detta kan vara användbart när du kanske vill skicka in antingen en modellhanterare eller en QuerySet och göra ytterligare filtrering av resultatet. Efter att du har anropat all() för något av objekten har du garanterat en QuerySet att arbeta med.
När en QuerySet evaluated utvärderas, lagras resultaten i cachen. Om data i databasen kan ha ändrats sedan en QuerySet utvärderades kan du få uppdaterade resultat för samma fråga genom att anropa all() på en tidigare utvärderad QuerySet.
union()Link to this heading#Använder SQL:s operator UNION för att kombinera resultaten från två eller flera QuerySet. Till exempel:
>>> qs1.union(qs2, qs3)\nOperatorn UNION väljer som standard endast distinkta värden. För att tillåta duplicerade värden, använd argumentet all=True.
union(), intersection() och difference() returnerar modellinstanser av typen för den första QuerySet även om argumenten är QuerySet av andra modeller. Att skicka olika modeller fungerar så länge som SELECT-listan är densamma i alla QuerySet (åtminstone typerna, namnen spelar ingen roll så länge som typerna är i samma ordning). I sådana fall måste du använda kolumnnamnen från det första QuerySet i QuerySet-metoder som tillämpas på det resulterande QuerySet. Till exempel:
>>> qs1 = Author.objects.values_list("name")\n>>> qs2 = Entry.objects.values_list("headline")\n>>> qs1.union(qs2).order_by("name")\nDessutom är endast LIMIT, OFFSET, COUNT(*), ORDER BY och angivande av kolumner (dvs. skivning, count(), exists(), order_by() och values()/values_list()) tillåtna för den resulterande QuerySet. Databaser begränsar dessutom vilka operationer som tillåts i de kombinerade frågorna. De flesta databaser tillåter till exempel inte LIMIT eller OFFSET i kombinerade frågor.
intersektion()Link to this heading#Använder SQL:s operator INTERSECT för att returnera de delade elementen i två eller flera QuerySet. Till exempel:
>>> qs1.intersection(qs2, qs3)\nSe union() för vissa begränsningar.
skillnad()Link to this heading#Använder SQL:s operator EXCEPT för att endast behålla element som finns i QuerySet men inte i några andra QuerySet. Till exempel:
>>> qs1.difference(qs2, qs3)\nSe union() för vissa begränsningar.
fetch_mode()Link to this heading#Returnerar en QuerySet som anger det givna hämtningsläget för alla modellinstanser som skapas av denna QuerySet. Hämtningsläget styr inläsning av fält vid behov när de används, till exempel för främmande nycklar och uppskjutna fält. För att till exempel använda läget FETCH_PEERS för att gruppvis läsa in alla relaterade objekt vid första åtkomst:
from django.db import models\n\nbooks = Book.objects.fetch_mode(models.FETCH_PEERS)\nSe mer i ämnesguiden för hämtningslägen.
\nextra()Link to this heading#Ibland kan Djangos frågesyntax i sig inte enkelt uttrycka en komplex WHERE-klausul. För dessa kantfall tillhandahåller Django modifieraren extra() QuerySet - en hook för att injicera specifika klausuler i SQL som genereras av en QuerySet.
Per definition kan dessa extra uppslagningar inte vara portabla till olika databasmotorer (eftersom du uttryckligen skriver SQL-kod) och bryter mot DRY-principen, så du bör undvika dem om möjligt.
\nAnge ett eller flera av params, select, where eller tables. Inget av argumenten är obligatoriskt, men du bör använda minst ett av dem.
välja
Argumentet select låter dig lägga till extra fält i SELECT-satsen. Det ska vara en ordbok som kopplar attributnamn till SQL-satser som används för att beräkna attributet.
Exempel:
\nEntry.objects.extra(select={"is_recent": "pub_date > '2006-01-01'"})\nSom ett resultat kommer varje Entry-objekt att ha ett extra attribut, is_recent, ett boolean som anger om postens pub_date är större än 1 januari 2006.
Django infogar det angivna SQL-utdraget direkt i SELECT-satsen, så den resulterande SQL i ovanstående exempel skulle vara något liknande:
SELECT blog_entry.*, (pub_date > '2006-01-01') AS is_recent\nFROM blog_entry;\nNästa exempel är mer avancerat; det gör en underfråga för att ge varje resulterande Blog-objekt ett entry_count-attribut, ett heltalsantal av associerade Entry-objekt:
Blog.objects.extra(\n select={\n "entry_count": "SELECT COUNT(*) FROM blog_entry WHERE blog_entry.blog_id = blog_blog.id"\n },\n)\nI detta speciella fall utnyttjar vi det faktum att frågan redan kommer att innehålla tabellen blog_blog i sin FROM-klausul.
Den resulterande SQL i ovanstående exempel skulle vara:
\nSELECT blog_blog.*, (SELECT COUNT(*) FROM blog_entry WHERE blog_entry.blog_id = blog_blog.id) AS entry_count\nFROM blog_blog;\nObservera att de parenteser som krävs av de flesta databasmotorer runt underfrågor inte krävs i Djangos select-klausuler.
I vissa sällsynta fall kan du vilja skicka parametrar till SQL-fragmenten i extra(select=...). För detta ändamål använder du parametern select_params.
Detta kommer att fungera, till exempel:
\nBlog.objects.extra(\n select={"a": "%s", "b": "%s"},\n select_params=("one", "two"),\n)\nOm du behöver använda en bokstavlig %s i din select-sträng använder du sekvensen %%s.
where / tables
Du kan definiera explicita SQL WHERE-klausuler - kanske för att utföra icke-explicita sammanfogningar - genom att använda where. Du kan manuellt lägga till tabeller i SQL-satsen FROM med hjälp av tables.
where och tables tar båda emot en lista med strängar. Alla where parametrar är ”AND”ed till alla andra sökkriterier.
Exempel:
\nEntry.objects.extra(where=["foo='a' OR bar = 'a'", "baz = 'a'"])\n…översätts (ungefär) till följande SQL:
\nSELECT * FROM blog_entry WHERE (foo='a' OR bar='a') AND (baz='a')\nVar försiktig när du använder parametern tables om du anger tabeller som redan används i frågan. När du lägger till extra tabeller via parametern tables antar Django att du vill att den tabellen ska inkluderas en extra gång, om den redan är inkluderad. Det skapar ett problem, eftersom tabellnamnet då får ett alias. Om en tabell förekommer flera gånger i en SQL-sats måste den andra och efterföljande förekomsterna använda alias så att databasen kan skilja dem åt. Om du hänvisar till den extra tabellen som du lade till i den extra where-parametern kommer detta att orsaka fel.
Normalt lägger du bara till extra tabeller som inte redan finns i frågan. Men om det fall som beskrivs ovan inträffar finns det några lösningar. Först kan du se om du kan klara dig utan att inkludera den extra tabellen och använda den som redan finns i frågan. Om det inte är möjligt, placera ditt extra()-anrop längst fram i queryset-konstruktionen så att din tabell är den första användningen av den tabellen. Slutligen, om allt annat misslyckas, titta på den query som producerats och skriv om ditt where-tillägg för att använda det alias som ges till din extra tabell. Aliaset kommer att vara detsamma varje gång du konstruerar queryset på samma sätt, så du kan lita på att aliasnamnet inte ändras.
order_by
Om du behöver sortera den resulterande frågeuppsättningen med några av de nya fälten eller tabellerna som du har inkluderat via extra(), använd parametern order_by för extra() och skicka in en följd av strängar. Strängarna ska antingen vara modellfält (som i den vanliga order_by()-metoden för frågeuppsättningar), ha formen table_name.column_name eller vara ett alias för en kolumn som du angav i select-parametern till extra().
Till exempel:
\nq = Entry.objects.extra(select={"is_recent": "pub_date > '2006-01-01'"})\nq = q.extra(order_by=["-is_recent"])\nDetta skulle sortera alla objekt för vilka is_recent är sant längst fram i resultatuppsättningen (True sorteras före False i en fallande ordning).
Detta visar förresten att du kan göra flera anrop till extra() och att det kommer att bete sig som du förväntar dig (lägga till nya begränsningar varje gång).
params
Parametern where som beskrivs ovan kan använda Pythons standardplatshållare för databassträngar - '%s' för att ange parametrar som databasmotorn automatiskt ska citera. Argumentet params är en lista över eventuella extra parametrar som ska ersättas.
Exempel:
\nEntry.objects.extra(where=["headline=%s"], params=["Lennon"])\nAnvänd alltid params istället för att bädda in värden direkt i where eftersom params ser till att värdena citeras korrekt enligt din specifika backend. Till exempel: kommer citattecken att escapas korrekt.
Dålig:
\nEntry.objects.extra(where=["headline='Lennon'"])\nBra:
\nEntry.objects.extra(where=["headline=%s"], params=["Lennon"])\ndefer()Link to this heading#I vissa komplexa datamodelleringssituationer kan dina modeller innehålla många fält, varav vissa kan innehålla mycket data (till exempel textfält) eller kräva dyr bearbetning för att konvertera dem till Python-objekt. Om du använder resultaten av en queryset i en situation där du inte vet om du behöver just de här fälten när du först hämtar data, kan du säga till Django att inte hämta dem från databasen.
\nDetta görs genom att skicka namnen på de fält som inte ska laddas till defer():
Entry.objects.defer("headline", "body")\nEn queryset som har uppskjutna fält kommer fortfarande att returnera modellinstanser. Varje uppskjutet fält hämtas från databasen om du öppnar det fältet (ett i taget, inte alla uppskjutna fält på en gång).
\n\nDu kan göra flera anrop till defer(). Varje anrop lägger till nya fält i den uppskjutna uppsättningen:
# Defers both the body and headline fields.\nEntry.objects.defer("body").filter(rating=5).defer("headline")\nOrdningen i vilken fälten läggs till i den uppskjutna uppsättningen spelar ingen roll. Att anropa defer() med ett fältnamn som redan har skjutits upp är ofarligt (fältet kommer fortfarande att skjutas upp).
Du kan skjuta upp inläsningen av fält i relaterade modeller (om de relaterade modellerna läses in via select_related()) med den vanliga dubbla understrecknotationen för att separera relaterade fält:
Blog.objects.select_related().defer("entry__headline", "entry__body")\nOm du vill rensa uppsättningen av uppskjutna fält, skicka None som en parameter till defer():
# Load all fields immediately.\nmy_queryset.defer(None)\nVissa fält i en modell skjuts inte upp även om du begär det. Du kan aldrig skjuta upp inläsningen av primärnyckeln. Om du använder select_related() för att hämta relaterade modeller bör du inte skjuta upp inläsningen av fältet som ansluter den primära modellen till den relaterade, eftersom det leder till ett fel.
På samma sätt är det inte meningsfullt att anropa defer() (eller motsvarigheten only()) med ett argument från en aggregering (t.ex. med resultatet av annotate()): om du gör det utlöses ett undantag. De aggregerade värdena hämtas alltid till den resulterande frågeuppsättningen.
only()Link to this heading#Metoden only() är i princip motsatsen till defer(). Endast de fält som skickas till den här metoden och som inte redan har angetts som uppskjutna laddas omedelbart när frågeuppsättningen utvärderas.
Om du har en modell där nästan alla fält måste skjutas upp kan du använda only() för att ange den kompletterande uppsättningen fält, vilket kan resultera i enklare kod.
Anta att du har en modell med fälten namn, ålder och biografi. Följande två frågeuppsättningar är desamma när det gäller uppskjutna fält:
Person.objects.defer("age", "biography")\nPerson.objects.only("name")\nNär du anropar only() ersätter den uppsättning fält som ska laddas omedelbart. Metodens namn är ett minnesmärke: endast dessa fält laddas omedelbart; resten skjuts upp. Successiva anrop till only() resulterar således i att endast de sista fälten beaktas:
# This will defer all fields except the headline.\nEntry.objects.only("body", "rating").only("headline")\nEftersom defer() agerar stegvis (lägger till fält i den uppskjutna listan) kan du kombinera anrop till only() och defer() och saker och ting kommer att bete sig logiskt:
# Final result is that everything except "headline" is deferred.\nEntry.objects.only("headline", "body").defer("body")\n\n# Final result loads headline immediately.\nEntry.objects.defer("body").only("headline", "body")\nAlla varningar i anmärkningen för defer()-dokumentationen gäller även för only(). Använd den försiktigt och endast efter att ha uttömt dina andra alternativ.
Att använda only() och utelämna ett fält som begärts med select_related() är också ett fel. Å andra sidan kommer anrop av only() utan några argument att returnera alla fält (inklusive annoteringar) som hämtats av queryset.
Precis som med defer() kan du inte komma åt de icke-laddade fälten från asynkron kod och förvänta dig att de laddas. Istället kommer du att få ett SynchronousOnlyOperation undantag. Se till att alla fält som du kan komma åt finns i ditt only()-anrop.
using()Link to this heading#Den här metoden används för att styra mot vilken databas QuerySet ska utvärderas om du använder fler än en databas. Det enda argument som metoden tar är aliaset för en databas, enligt definitionen i DATABASES.
Till exempel:
\n# queries the database with the 'default' alias.\n>>> Entry.objects.all()\n\n# queries the database with the 'backup' alias\n>>> Entry.objects.using("backup")\nselect_for_update()Link to this heading#Returnerar en queryset som låser rader till slutet av transaktionen, vilket genererar en SQL-sats SELECT ... FOR UPDATE på databaser som stöds.
Till exempel:
\nfrom django.db import transaction\n\nentries = Entry.objects.select_for_update().filter(author=request.user)\nwith transaction.atomic():\n for entry in entries:\n ...\nNär queryset utvärderas (i det här fallet for entry in entries) kommer alla matchade poster att låsas fram till slutet av transaktionsblocket, vilket innebär att andra transaktioner inte kan ändra eller förvärva lås på dem.
Om en annan transaktion redan har skaffat ett lås på en av de valda raderna blockeras vanligtvis frågan tills låset frigörs. Om detta inte är det beteende du vill ha kan du anropa select_for_update(nowait=True). Detta gör anropet icke-blockerande. Om ett motstridigt lås redan har förvärvats av en annan transaktion, kommer DatabaseError att tas upp när queryset utvärderas. Du kan också ignorera låsta rader genom att använda select_for_update(skip_locked=True) istället. Alternativen nowait och skip_locked är ömsesidigt uteslutande och försök att anropa select_for_update() med båda alternativen aktiverade kommer att resultera i ett ValueError.
Som standard låser select_for_update() alla rader som väljs av frågan. Till exempel: låses rader med relaterade objekt som anges i select_related() utöver raderna i frågeuppsättningens modell. Om detta inte är önskvärt kan du ange de relaterade objekt som du vill låsa i select_for_update(of=(...)) med samma fältsyntax som i select_related(). Använd värdet 'self' för att hänvisa till frågeuppsättningens modell.
Endast på PostgreSQL kan du skicka `` no_key = True `` för att få ett svagare lås, som fortfarande tillåter att skapa rader som bara refererar till låsta rader (till exempel genom en främmande nyckel) medan låset är på plats. PostgreSQL-dokumentationen har mer information om låslägen på radnivå <https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS>`_.
\nDu kan inte använda select_for_update() på nullable-relationer:
>>> Person.objects.select_related("hometown").select_for_update()\nTraceback (most recent call last):\n...\ndjango.db.utils.NotSupportedError: FOR UPDATE cannot be applied to the nullable side of an outer join\nFör att undvika den begränsningen kan du utesluta null-objekt om du inte bryr dig om dem:
\n>>> Person.objects.select_related("hometown").select_for_update().exclude(hometown=None)\n<QuerySet [<Person: ...>, ...]>\nDatabasbackendarna postgresql, oracle och mysql stöder select_for_update(). MariaDB stöder dock endast argumenten nowait och skip_locked, och MySQL stöder argumenten nowait, skip_locked och of. Argumentet no_key stöds endast av PostgreSQL.
Att skicka nowait=True, skip_locked=True, no_key=True eller of till select_for_update() med databasbackends som inte stöder dessa alternativ, till exempel MySQL, ger upphov till ett NotSupportedError. Detta förhindrar att koden oväntat blockeras.
Att utvärdera en queryset med select_for_update() i autocommit-läge på backends som stöder SELECT ... FOR UPDATE är ett TransactionManagementError-fel eftersom raderna inte är låsta i det fallet. Om det var tillåtet skulle detta underlätta datakorruption och kan lätt orsakas av anropande kod som förväntar sig att köras i en transaktion utanför en transaktion.
Att använda select_for_update() på backends som inte stöder SELECT ... FOR UPDATE (t.ex. SQLite) har ingen effekt. SELECT ... FOR UPDATE läggs inte till i frågan och ett fel uppstår inte om select_for_update() används i autocommit-läge.
raw()Link to this heading#Tar en rå SQL-fråga, kör den och returnerar en django.db.models.query.RawQuerySet-instans. Denna RawQuerySet-instans kan itereras över precis som en vanlig QuerySet för att tillhandahålla objektinstanser.
Se Utföra SQL-frågor i råformat för mer information.
\n\nQuerySetLink to this heading#Kombinerade querysets måste använda samma modell.
\n&)Link to this heading#Kombinerar två QuerySet med SQL-operatorn AND på ett sätt som liknar kedjning av filter.
Följande är likvärdiga:
\nModel.objects.filter(x=1) & Model.objects.filter(y=2)\nModel.objects.filter(x=1).filter(y=2)\nSQL-ekvivalent:
\nSELECT ... WHERE x=1 AND y=2\n|)Link to this heading#Kombinerar två QuerySet med hjälp av SQL-operatorn OR.
Följande är likvärdiga:
\nModel.objects.filter(x=1) | Model.objects.filter(y=2)\nfrom django.db.models import Q\n\nModel.objects.filter(Q(x=1) | Q(y=2))\nSQL-ekvivalent:
\nSELECT ... WHERE x=1 OR y=2\n| är inte en kommutativ operation, eftersom olika (men likvärdiga) frågor kan genereras.
^)Link to this heading#Kombinerar två QuerySet med hjälp av SQL-operatorn XOR. Ett XOR-uttryck matchar rader som matchas av ett udda antal operander.
Följande är likvärdiga:
\nModel.objects.filter(x=1) ^ Model.objects.filter(y=2)\nfrom django.db.models import Q\n\nModel.objects.filter(Q(x=1) ^ Q(y=2))\nSQL-ekvivalent:
\nSELECT ... WHERE x=1 XOR y=2\nQuerySetLink to this heading#Följande QuerySet-metoder utvärderar QuerySet och returnerar något annat än ett QuerySet.
Dessa metoder använder inte en cache (se Cachelagring och ”QuerySet). Istället frågar de databasen varje gång de anropas.
\nEftersom dessa metoder utvärderar QuerySet är de blockerande anrop, och därför kan deras huvudsakliga (synkrona) versioner inte anropas från asynkron kod. Av denna anledning har var och en en motsvarande asynkron version med prefixet a - till exempel, i stället för get(...) kan du await aget(...).
Det finns vanligtvis ingen skillnad i beteende bortsett från deras asynkrona natur, men eventuella skillnader noteras nedan bredvid varje metod.
\nget()Link to this heading#Asynkron version: aget()
Returnerar objektet som matchar de angivna parametrarna för lookup, som bör vara i det format som beskrivs i Field lookups. Du bör använda uppslagningar som garanterat är unika, t.ex. primärnyckeln eller fält i en unik begränsning. Till exempel:
\nEntry.objects.get(id=1)\nEntry.objects.get(Q(blog=blog) & Q(entry_number=1))\nOm du förväntar dig att en queryset redan ska returnera en rad kan du använda get() utan några argument för att returnera objektet för den raden:
Entry.objects.filter(pk=1).get()\nOm get() inte hittar något objekt, uppstår ett Model.DoesNotExist undantag:
Entry.objects.get(id=-999) # raises Entry.DoesNotExist\nOm get() hittar mer än ett objekt, ger det upphov till ett Model.MultipleObjectsReturned undantag:
Entry.objects.get(name="A Duplicated Name") # raises Entry.MultipleObjectsReturned\nBåda dessa undantagsklasser är attribut till modellklassen och är specifika för den modellen. Om du vill hantera sådana undantag från flera get()-anrop för olika modeller kan du använda deras generiska basklasser. Du kan t.ex. använda django.core.exceptions.ObjectDoesNotExist för att hantera DoesNotExist undantag från flera modeller:
from django.core.exceptions import ObjectDoesNotExist\n\ntry:\n blog = Blog.objects.get(id=1)\n entry = Entry.objects.get(blog=blog, entry_number=1)\nexcept ObjectDoesNotExist:\n print("Either the blog or entry doesn't exist.")\ncreate()Link to this heading#Asynkron version: acreate()
En bekvämlighetsmetod för att skapa ett objekt och spara allt i ett enda steg. Alltså:
\np = Person.objects.create(first_name="Bruce", last_name="Springsteen")\noch:
\np = Person(first_name="Bruce", last_name="Springsteen")\np.save(force_insert=True)\när likvärdiga.
\nParametern force_insert finns dokumenterad på annat håll, men allt den innebär är att ett nytt objekt alltid kommer att skapas. Normalt behöver du inte oroa dig för detta. Men om din modell innehåller ett manuellt primärnyckelvärde som du ställer in och om det värdet redan finns i databasen, kommer ett anrop till create() att misslyckas med en IntegrityError eftersom primärnycklar måste vara unika. Var beredd på att hantera undantaget om du använder manuella primärnycklar.
get_or_create()Link to this heading#Asynkron version: aget_or_create()
En bekväm metod för att leta upp ett objekt med de angivna kwargs (kan vara tomt om din modell har standardvärden för alla fält), och skapa ett om det behövs.
Returnerar en tupel av (object, created), där object är det hämtade eller skapade objektet och created är en boolean som anger om ett nytt objekt skapades.
Detta är tänkt att förhindra att duplicerade objekt skapas när förfrågningar görs parallellt, och som en genväg till boilerplatish-kod. Till exempel:
\ntry:\n obj = Person.objects.get(first_name="John", last_name="Lennon")\nexcept Person.DoesNotExist:\n obj = Person(first_name="John", last_name="Lennon", birthday=date(1940, 10, 9))\n obj.save()\nHär, med samtidiga förfrågningar, kan flera försök att spara en Person med samma parametrar göras. För att undvika detta race condition kan exemplet ovan skrivas om med hjälp av get_or_create() på följande sätt:
obj, created = Person.objects.get_or_create(\n first_name="John",\n last_name="Lennon",\n defaults={"birthday": date(1940, 10, 9)},\n)\nAlla nyckelordsargument som skickas till get_or_create() – utom ett valfritt argument som heter defaults – används i ett get()-anrop. Om ett objekt hittas returnerar get_or_create() en tuppel med objektet och False.
Du kan ange mer komplexa villkor för det hämtade objektet genom att kedja get_or_create() med filter() och använda Q-objekt. Till exempel för att hämta Robert eller Bob Marley om någon av dem finns, och annars skapa den senare:
from django.db.models import Q\n\nobj, created = Person.objects.filter(\n Q(first_name="Bob") | Q(first_name="Robert"),\n).get_or_create(last_name="Marley", defaults={"first_name": "Bob"})\nOm flera objekt hittas, ger get_or_create() upphov till MultipleObjectsReturned. Om ett objekt inte hittas kommer get_or_create() att instansiera och spara ett nytt objekt och returnera en tupel av det nya objektet och True. Det nya objektet kommer att skapas ungefär enligt denna algoritm:
params = {k: v for k, v in kwargs.items() if "__" not in k}\nparams.update({k: v() if callable(v) else v for k, v in defaults.items()})\nobj = self.model(**params)\nobj.save()\nPå engelska betyder det att du börjar med alla nyckelordsargument som inte är defaults och som inte innehåller ett dubbelt understreck (vilket skulle indikera en icke-exakt uppslagning). Lägg sedan till innehållet i defaults, åsidosätt eventuella nycklar om det behövs, och använd resultatet som nyckelordsargument till modellklassen. Om det finns några callables i defaults, utvärdera dem. Som antyddes ovan är detta en förenkling av den algoritm som används, men den innehåller alla relevanta detaljer. Den interna implementationen har lite mer felkontroll än detta och hanterar några extra kantvillkor; om du är intresserad, läs koden.
Om du har ett fält som heter defaults och vill använda det som en exakt uppslagning i get_or_create(), använder du 'defaults__exact', så här:
Foo.objects.get_or_create(defaults__exact="bar", defaults={"defaults": "baz"})\nMetoden get_or_create() har ett liknande felbeteende som create() när du använder manuellt angivna primärnycklar. Om ett objekt behöver skapas och nyckeln redan finns i databasen utlöses en IntegrityError.
Slutligen, ett ord om att använda get_or_create() i Django-vyer. Se till att endast använda den i POST-förfrågningar om du inte har en bra anledning att inte göra det. GET-förfrågningar bör inte ha någon effekt på data. Använd istället POST när en begäran till en sida har en sidoeffekt på dina data. För mer information, se Säkra metoder i HTTP-specifikationen.
uppdatera_eller_skapa()Link to this heading#Asynkron version: aupdate_or_create()
En bekvämlighetsmetod för att uppdatera ett objekt med de givna kwargs, och skapa ett nytt om det behövs. Både create_defaults och defaults är dictionaries av (fält, värde) par. Värdena i både create_defaults och defaults kan vara callables. defaults används för att uppdatera objektet medan create_defaults används för create-operationen. Om create_defaults inte anges kommer defaults att användas för att skapa objektet.
Returnerar en tupel av (object, created), där object är det skapade eller uppdaterade objektet och created är en boolean som anger om ett nytt objekt skapades.
Metoden update_or_create försöker hämta ett objekt från databasen baserat på de givna kwargs. Om en matchning hittas, uppdateras fälten som skickas i defaults dictionary.
Detta är tänkt som en genväg till standardkod. Till exempel:
\ndefaults = {"first_name": "Bob"}\ncreate_defaults = {"first_name": "Bob", "birthday": date(1940, 10, 9)}\ntry:\n obj = Person.objects.get(first_name="John", last_name="Lennon")\n for key, value in defaults.items():\n setattr(obj, key, value)\n obj.save()\nexcept Person.DoesNotExist:\n new_values = {"first_name": "John", "last_name": "Lennon"}\n new_values.update(create_defaults)\n obj = Person(**new_values)\n obj.save()\nDet här mönstret blir ganska otympligt när antalet fält i en modell ökar. Exemplet ovan kan skrivas om med hjälp av update_or_create() på följande sätt:
obj, created = Person.objects.update_or_create(\n first_name="John",\n last_name="Lennon",\n defaults={"first_name": "Bob"},\n create_defaults={"first_name": "Bob", "birthday": date(1940, 10, 9)},\n)\nFör en detaljerad beskrivning av hur namn som skickas i kwargs löses, se get_or_create().
Såsom beskrivs ovan i get_or_create(), är den här metoden känslig för ett tävlingsförhållande som kan leda till att flera rader infogas samtidigt om unikhet inte upprätthålls på databasnivå.
Precis som get_or_create() och create(), om du använder manuellt angivna primära nycklar och ett objekt behöver skapas men nyckeln redan finns i databasen, kommer ett IntegrityError att uppstå.
bulk_create()Link to this heading#Asynkron version: abulk_create()
Den här metoden infogar den angivna listan med objekt i databasen på ett effektivt sätt (i allmänhet bara 1 fråga, oavsett hur många objekt det finns) och returnerar skapade objekt som en lista i samma ordning som den angivna:
\n>>> objs = Entry.objects.bulk_create(\n... [\n... Entry(headline="This is a test"),\n... Entry(headline="This is only a test"),\n... ]\n... )\nDetta har dock ett antal förbehåll:
\nModellens save()-metod anropas inte, och signalerna pre_save och post_save skickas inte.
Det fungerar inte med underordnade modeller i ett arvsscenario med flera tabeller.
Om modellens primärnyckel är ett AutoField eller har ett db_default-värde, och ignore_conflicts är False, kan primärnyckelattributet bara hämtas i vissa databaser (för närvarande PostgreSQL, MariaDB och SQLite). I andra databaser anges det inte.
Det fungerar inte med många-till-manga-relationer.
Den kastar objs till en lista, som fullt ut utvärderar objs om det är en generator. Castet gör det möjligt att inspektera alla objekt så att alla objekt med en manuellt inställd primärnyckel kan infogas först. Om du vill infoga objekt i satser utan att utvärdera hela generatorn på en gång kan du använda den här tekniken så länge objekten inte har några manuellt inställda primära nycklar:
from itertools import islice\n\nbatch_size = 100\nobjs = (Entry(headline="Test %s" % i) for i in range(1000))\nwhile True:\n batch = list(islice(objs, batch_size))\n if not batch:\n break\n Entry.objects.bulk_create(batch, batch_size)\nParametern batch_size styr hur många objekt som skapas i en enskild fråga. Standardinställningen är att skapa så många objekt i en batch som databasen tillåter. (SQLite och Oracle begränsar antalet parametrar i en fråga.)
I databaser som stöder detta (alla utom Oracle) kan parametern ignore_conflicts ställas in på True, vilket innebär att databasen ignorerar misslyckanden med att infoga rader som inte uppfyller begränsningar som t.ex. duplicerade unika värden.
På databaser som stöder det (alla utom Oracle), genom att ställa in parametern update_conflicts till True, berättar databasen att uppdatera update_fields när en radinsättning misslyckas med konflikter. På PostgreSQL och SQLite, förutom update_fields, måste en lista över unique_fields som kan vara i konflikt tillhandahållas.
Om parametern ignore_conflicts aktiveras inaktiveras inställningen av primärnyckeln för varje modellinstans (om databasen normalt stöder detta).
bulk_update()Link to this heading#Asynkron version: abulk_update()
Denna metod uppdaterar effektivt de angivna fälten på de angivna modellinstanserna, vanligtvis med en fråga, och returnerar antalet uppdaterade objekt:
\n>>> objs = [\n... Entry.objects.create(headline="Entry 1"),\n... Entry.objects.create(headline="Entry 2"),\n... ]\n>>> objs[0].headline = "This is entry 1"\n>>> objs[1].headline = "This is entry 2"\n>>> Entry.objects.bulk_update(objs, ["headline"])\n2\nQuerySet.update() används för att spara ändringarna, så det här är effektivare än att iterera genom listan med modeller och anropa save() på var och en av dem, men det har några förbehåll:
Du kan inte uppdatera modellens primärnyckel.
Varje modells save()-metod anropas inte, och signalerna pre_save och post_save skickas inte.
Om du uppdaterar ett stort antal kolumner i ett stort antal rader kan den SQL som genereras bli mycket stor. Undvik detta genom att ange en lämplig batch_size.
När du uppdaterar ett stort antal objekt bör du vara medveten om att bulk_update() förbereder alla WHEN-klausuler för varje objekt i alla batchar innan några frågor körs. Detta kan kräva mer minne än förväntat. För att minska minnesanvändningen kan du använda en metod som denna:
from itertools import islice\n\nbatch_size = 100\nids_iter = iter(range(1000))\nwhile ids := list(islice(ids_iter, batch_size)):\n batch = Entry.objects.filter(id__in=ids)\n for entry in batch:\n entry.headline = f"Updated headline {entry.pk}"\n Entry.objects.bulk_update(batch, ["headline"], batch_size=batch_size)\nUppdatering av fält som definieras på förfäder med flera tabeller kommer att medföra en extra fråga per förfader.
När en enskild batch innehåller dubbletter kommer endast den första förekomsten i den batchen att resultera i en uppdatering.
Det antal uppdaterade objekt som returneras av funktionen kan vara färre än det antal objekt som skickades in. Detta kan bero på duplicerade objekt som skickas in och som uppdateras i samma batch eller tävlingsförhållanden som gör att objekten inte längre finns i databasen.
Parametern batch_size styr hur många objekt som sparas i en enda fråga. Standardinställningen är att uppdatera alla objekt i en batch, med undantag för SQLite och Oracle som har begränsningar för antalet variabler som används i en fråga.
count()Link to this heading#Asynkron version: acount()
Returnerar ett heltal som representerar antalet objekt i databasen som matchar QuerySet.
Exempel:
\n# Returns the total number of entries in the database.\nEntry.objects.count()\n\n# Returns the number of entries whose headline contains 'Lennon'\nEntry.objects.filter(headline__contains="Lennon").count()\nEtt count()-anrop utför en SELECT COUNT(*) bakom kulisserna, så du bör alltid använda count() hellre än att ladda alla poster i Python-objekt och anropa len() på resultatet (såvida du inte behöver ladda objekten i minnet ändå, i vilket fall len() kommer att vara snabbare).
Observera att om du vill ha antalet objekt i en QuerySet och även hämtar modellinstanser från den (t.ex. genom att iterera över den), är det förmodligen effektivare att använda len(queryset) som inte orsakar en extra databasfråga som count() skulle göra.
Om frågeuppsättningen redan har hämtats i sin helhet kommer count() att använda den längden i stället för att göra en extra databasförfrågan.
in_bulk()Link to this heading#Asynkron version: ain_bulk()
Tar en lista med fältvärden (id_list) och field_name för dessa värden och returnerar en ordbok som mappar varje värde till en instans av objektet med det angivna fältvärdet. Inga django.core.exceptions.ObjectDoesNotExist-undantag kommer någonsin att skapas av in_bulk; det vill säga, alla id_list-värden som inte matchar någon instans kommer helt enkelt att ignoreras. Om id_list inte anges returneras alla objekt i queryset. field_name måste vara ett unikt fält eller ett distinkt fält (om det bara finns ett fält som anges i distinct()). field_name är som standard den primära nyckeln.
Exempel:
\n>>> Blog.objects.in_bulk([1])\n{1: <Blog: Beatles Blog>}\n>>> Blog.objects.in_bulk([1, 2])\n{1: <Blog: Beatles Blog>, 2: <Blog: Cheddar Talk>}\n>>> Blog.objects.in_bulk([])\n{}\n>>> Blog.objects.in_bulk()\n{1: <Blog: Beatles Blog>, 2: <Blog: Cheddar Talk>, 3: <Blog: Django Weblog>}\n>>> Blog.objects.in_bulk(["beatles_blog"], field_name="slug")\n{'beatles_blog': <Blog: Beatles Blog>}\n>>> Blog.objects.distinct("name").in_bulk(field_name="name")\n{'Beatles Blog': <Blog: Beatles Blog>, 'Cheddar Talk': <Blog: Cheddar Talk>, 'Django Weblog': <Blog: Django Weblog>}\nOm du skickar en tom lista till in_bulk() får du en tom ordbok.
iterator()Link to this heading#Asynkron version: aiterator()
Utvärderar QuerySet (genom att utföra frågan) och returnerar en iterator över resultaten, eller en asynchronous iterator om du anropar den asynkrona versionen aiterator.
En QuerySet cachelagrar vanligtvis sina resultat internt så att upprepade utvärderingar inte leder till ytterligare frågor. iterator() läser däremot resultaten direkt utan att cachelagra på QuerySet-nivå. För en QuerySet som returnerar ett stort antal objekt som du bara behöver komma åt en gång kan detta ge bättre prestanda och en betydande minskning av minnesanvändningen.
Observera att om du använder iterator() på en QuerySet som redan har utvärderats, tvingas den att utvärderas igen, vilket innebär att frågan upprepas.
iterator() är kompatibel med tidigare anrop till prefetch_related() så länge som chunk_size anges. Större värden kräver färre frågor för att åstadkomma prefetching till priset av större minnesanvändning.
I vissa databaser (t.ex. Oracle, SQLite) kan det maximala antalet termer i en SQL IN-klausul vara begränsat. Därför bör värden under denna gräns användas. (I synnerhet vid prefetching över två eller flera relationer bör en chunk_size vara tillräckligt liten för att det förväntade antalet resultat för varje prefetched relation fortfarande faller under gränsen)
Så länge QuerySet inte hämtar några relaterade objekt i förväg, kommer Django att använda en implicit standard på 2000 om man inte anger något värde för chunk_size.
Beroende på databasens backend kommer sökresultaten antingen att laddas på en gång eller strömmas från databasen med hjälp av cursorer på serversidan.
\nOracle och PostgreSQL använder markörer på serversidan för att strömma resultat från databasen utan att ladda hela resultatuppsättningen i minnet.
\nOracle-databasdrivrutinen använder alltid markörer på serversidan.
\nMed markörer på serversidan anger parametern chunk_size antalet resultat som ska cachas på databasdrivrutinsnivå. Genom att hämta större bitar minskas antalet rundresor mellan databasdrivrutinen och databasen, men det kostar minne.
På PostgreSQL kommer markörer på serversidan endast att användas när inställningen DISABLE_SERVER_SIDE_CURSORS <DATABASE-DISABLE_SERVER_SIDE_CURSORS>` är False. Läs Transaktionspoolning och cursorer på serversidan om du använder en anslutningspooler som är konfigurerad i transaktionspoolningsläge. När markörer på serversidan är inaktiverade är beteendet detsamma som i databaser som inte stöder markörer på serversidan.
MySQL stöder inte strömmande resultat, och därför laddar Python-databasdrivrutinen hela resultatuppsättningen i minnet. Resultatuppsättningen omvandlas sedan till Python-radobjekt av databasadaptern med hjälp av metoden fetchmany() som definieras i PEP 249.
SQLite kan hämta resultat i satser med fetchmany(), men eftersom SQLite inte tillhandahåller isolering mellan frågor inom en anslutning måste du vara försiktig när du skriver till den tabell som itereras över. Se Isolering vid användning av QuerySet.iterator() för mer information.
Parametern chunk_size styr storleken på de batcher som Django hämtar från databasdrivrutinen. Större satser minskar omkostnaderna för att kommunicera med databasdrivrutinen på bekostnad av en liten ökning av minnesförbrukningen.
Så länge som QuerySet inte hämtar några relaterade objekt, kommer inget värde för chunk_size att resultera i att Django använder en implicit standard på 2000, ett värde som härrör från en beräkning på psycopg-postlistan:
\n\nOm vi antar att raderna består av 10-20 kolumner med en blandning av text och numeriska data kommer 2000 att hämta mindre än 100 kB data, vilket verkar vara en bra kompromiss mellan antalet rader som överförs och den data som kasseras om loopen avslutas tidigt.
\n
nyaste()Link to this heading#Asynkron version: alatest()
Returnerar det senaste objektet i tabellen baserat på det eller de fält som anges.
\nI detta exempel returneras det senaste Entry i tabellen, enligt fältet pub_date:
Entry.objects.latest("pub_date")\nDu kan också välja den senaste baserat på flera fält. Till exempel:, för att välja den Entry med det tidigaste expire_date när två poster har samma pub_date:
Entry.objects.latest("pub_date", "-expire_date")\nDet negativa tecknet i '-expire_date' betyder att expire_date ska sorteras i fallande ordning. Eftersom latest() får det sista resultatet, väljs det Entry som har det tidigaste expire_date.
Om din modells Meta specificerar get_latest_by, kan du utelämna alla argument till earliest() eller latest(). De fält som anges i get_latest_by kommer att användas som standard.
Liksom get() utlöser earliest() och latest() DoesNotExist om det inte finns något objekt med de angivna parametrarna.
Observera att earliest() och latest() endast finns för bekvämlighetens och läsbarhetens skull.
earliest()Link to this heading#Asynkron version: aearliest()
Fungerar annars som latest() förutom att riktningen är ändrad.
första()Link to this heading#Asynkron version: afirst()
Returnerar det första objektet som matchar frågeuppsättningen, eller None om det inte finns något matchande objekt. Om QuerySet inte har någon definierad sortering (och sorteringen inte har rensats uttryckligen genom att anropa order_by() utan argument) sorteras frågeuppsättningen automatiskt efter primärnyckeln. Detta kan påverka aggregeringsresultat enligt beskrivningen i Interaktion med order_by().
Exempel:
\np = Article.objects.order_by("title", "pub_date").first()\nObservera att first() är en bekvämlighetsmetod, följande kodprov är likvärdigt med ovanstående exempel:
try:\n p = Article.objects.order_by("title", "pub_date")[0]\nexcept IndexError:\n p = None\nlast()Link to this heading#Asynkron version: alast()
Fungerar som first(), men returnerar det sista objektet i frågeuppsättningen.
aggregate()Link to this heading#Asynkron version: aaggregate()
Returnerar en ordbok med aggregerade värden (medelvärden, summor etc.) som beräknats över QuerySet. Varje argument till aggregate() anger ett värde som ska ingå i den ordbok som returneras.
De aggregeringsfunktioner som tillhandahålls av Django beskrivs i Aggregeringsfunktioner nedan. Eftersom aggregat också är query expressions, kan du kombinera aggregat med andra aggregat eller värden för att skapa komplexa aggregat.
\nAggregat som anges med nyckelordsargument kommer att använda nyckelordet som namn på annoteringen. För anonyma argument genereras ett namn som baseras på namnet på aggregatfunktionen och det modellfält som aggregeras. Komplexa aggregat kan inte använda anonyma argument utan måste ange ett nyckelordsargument som alias.
\nOm du t.ex. arbetar med blogginlägg kanske du vill veta hur många författare som har skrivit blogginlägg:
\n>>> from django.db.models import Count\n>>> Blog.objects.aggregate(Count("entry__authors"))\n{'entry__authors__count': 16}\nGenom att använda ett nyckelordsargument för att ange aggregeringsfunktionen kan du styra namnet på det aggregeringsvärde som returneras:
\n>>> Blog.objects.aggregate(number_of_authors=Count("entry__authors"))\n{'number_of_authors': 16}\nFör en djupgående diskussion om aggregering, se the topic guide on Aggregation.
\nexists()Link to this heading#Asynkron version: aexists()
Returnerar True om QuerySet innehåller några resultat, och False om inte. Detta försöker utföra frågan på enklast och snabbast möjliga sätt, men det kör nästan samma fråga som en normal QuerySet-fråga.
exists() är användbart för sökningar som gäller förekomsten av objekt i en QuerySet, särskilt i samband med en stor QuerySet.
För att ta reda på om en frågeuppsättning innehåller några objekt:
\nif some_queryset.exists():\n print("There is at least one object in some_queryset")\nVilket kommer att vara snabbare än:
\nif some_queryset:\n print("There is at least one object in some_queryset")\n… men inte i någon större utsträckning (vilket innebär att det krävs en stor frågeuppsättning för effektivitetsvinster).
\nDessutom, om en some_queryset ännu inte har utvärderats, men du vet att den kommer att göra det någon gång, kommer det att göra mer totalt arbete att använda some_queryset.exists() (en fråga för existenskontrollen plus en extra för att senare hämta resultaten) än att använda bool(some_queryset), som hämtar resultaten och sedan kontrollerar om några returnerades.
contains()Link to this heading#Asynkron version: acontains()
Returnerar True om QuerySet innehåller obj, och False om inte. Detta försöker utföra frågan på det enklaste och snabbaste sättet som möjligt.
contains() är användbart för att kontrollera ett objekts medlemskap i en QuerySet, särskilt i samband med en stor QuerySet.
För att kontrollera om en frågeuppsättning innehåller ett visst objekt:
\nif some_queryset.contains(obj):\n print("Entry contained in queryset")\nDetta går snabbare än följande, som kräver utvärdering och iteration genom hela frågeuppsättningen:
\nif obj in some_queryset:\n print("Entry contained in queryset")\nPrecis som exists(), om some_queryset ännu inte har utvärderats, men du vet att det kommer att utvärderas någon gång, kommer användningen av some_queryset.contains(obj) att göra en ytterligare databasförfrågan, vilket i allmänhet resulterar i långsammare prestanda.
uppdatera()Link to this heading#Asynkron version: aupdate()
Utför en SQL-uppdateringsfråga för de angivna fälten och returnerar antalet matchade rader (som kanske inte är lika med antalet uppdaterade rader om vissa rader redan har det nya värdet).
\nOm du t.ex. vill stänga av kommentarer för alla blogginlägg som publicerades 2010 kan du göra så här:
\n>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False)\n(Detta förutsätter att din Entry-modell har fälten pub_date och comments_on)
Du kan uppdatera flera fält - det finns ingen begränsning för hur många. Här uppdaterar vi till exempel fälten comments_on och headline:
>>> Entry.objects.filter(pub_date__year=2010).update(\n... comments_on=False, headline="This is old"\n... )\nMetoden update() tillämpas direkt, och den enda begränsningen för QuerySet som uppdateras är att den bara kan uppdatera kolumner i modellens huvudtabell, inte i relaterade modeller. Du kan till exempel inte göra så här:
>>> Entry.objects.update(blog__name="foo") # Won't work!\nDet är dock fortfarande möjligt att filtrera baserat på relaterade fält:
\n>>> Entry.objects.filter(blog__id=1).update(comments_on=True)\nDu kan inte anropa update() på en QuerySet som har fått en slice tagen eller på annat sätt inte längre kan filtreras.
Metoden update() returnerar antalet berörda rader:
>>> Entry.objects.filter(id=64).update(comments_on=True)\n1\n\n>>> Entry.objects.filter(slug="nonexistent-slug").update(comments_on=True)\n0\n\n>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False)\n132\nOm du bara uppdaterar en post och inte behöver göra något med modellobjektet är det effektivaste sättet att anropa update() i stället för att ladda modellobjektet i minnet. Till exempel:, istället för att göra så här:
e = Entry.objects.get(id=10)\ne.comments_on = False\ne.save()\n…gör så här:
\nEntry.objects.filter(id=10).update(comments_on=False)\nGenom att använda update() förhindras också ett tävlingsförhållande där något kan ändras i din databas under den korta tidsperioden mellan laddning av objektet och anrop av save().
Tänk slutligen på att update() gör en uppdatering på SQL-nivå och därför inte anropar några metoder save() på dina modeller och inte heller skickar signalerna pre_save eller post_save (som är en följd av att anropa Model.save()). Om du vill uppdatera en grupp poster för en modell som har en anpassad metod save() ska du iterera över dem och anropa save(), så här:
for e in Entry.objects.filter(pub_date__year=2010):\n e.comments_on = False\n e.save()\nAtt kedja order_by() med update() stöds endast av MariaDB och MySQL, och ignoreras för andra databaser. Detta är användbart för att uppdatera ett unikt fält i den ordning som anges utan konflikter. Till exempel:
Entry.objects.order_by("-number").update(number=F("number") + 1)\ndelete()Link to this heading#Asynkron version: adelete()
Utför en SQL-raderingsfråga för alla rader i QuerySet och returnerar antalet borttagna objekt samt en ordbok med antalet borttagningar per objekttyp. Returvärdet räknar instanser från relaterade modeller om Django emulerar kaskadbeteende via Python-varianter av on_delete. I annat fall rapporterar returvärdet, för databasvarianter som DB_CASCADE, endast instanser av QuerySet-modellen.
Delete() tillämpas omedelbart. Du kan inte anropa delete() på en QuerySet som har fått en slice tagen eller på annat sätt inte längre kan filtreras.
Till exempel: för att radera alla inlägg i en viss blogg:
\n>>> b = Blog.objects.get(pk=1)\n\n# Delete all the entries belonging to this Blog.\n>>> Entry.objects.filter(blog=b).delete()\n(4, {'blog.Entry': 2, 'blog.Entry_authors': 2})\nSom standard emulerar Djangos ForeignKey SQL-begränsningen ON DELETE CASCADE - med andra ord kommer alla objekt med utländska nycklar som pekar på de objekt som ska raderas att raderas tillsammans med dem. Till exempel:
>>> blogs = Blog.objects.all()\n\n# This will delete all Blogs and all of their Entry objects.\n>>> blogs.delete()\n(5, {'blog.Blog': 1, 'blog.Entry': 2, 'blog.Entry_authors': 2})\nDetta kaskadbeteende kan anpassas via argumentet on_delete till ForeignKey.
Metoden delete() utför en bulkradering och anropar inte några delete()-metoder för dina modeller. Den skickar dock signalerna pre_delete och post_delete för alla borttagna objekt (inklusive kaskadborttagningar). Signaler skickas inte när DB_CASCADE används. Dessutom returnerar delete() inte information om objekt som tagits bort av databasvarianter (DB_*) för argumentet on_delete, t.ex. DB_CASCADE.
Django behöver inte hämta objekt till minnet när de tas bort i följande fall:
\nOm relaterade fält använder DB_*-alternativ.
Om det inte finns några kaskader eller mottagare av raderingssignaler.
I dessa fall kan Django använda en snabbare väg och ta bort objekt utan att hämta dem, vilket kan ge betydligt lägre minnesanvändning och färre utförda frågor.
\nForeignKeys som är inställda på on_delete DO_NOTHING förhindrar inte att man tar den snabba vägen vid radering.
Observera att de frågor som genereras vid borttagning av objekt är en implementeringsdetalj som kan komma att ändras.
\n\nas_manager()Link to this heading#Klassmetod som returnerar en instans av Manager med en kopia av QuerySet’s metoder. Se Skapa en manager med QuerySet-metoder för mer information.
Observera att till skillnad från de andra posterna i detta avsnitt har denna inte en asynkron variant eftersom den inte exekverar en fråga.
\nexplain()Link to this heading#Asynkron version: aexplain()
Returnerar en sträng av QuerySet:s exekveringsplan, som innehåller information om hur databasen skulle exekvera frågan, inklusive eventuella index eller sammanfogningar som skulle användas. Om du känner till dessa detaljer kan det hjälpa dig att förbättra prestanda för långsamma frågor.
Till exempel: när du använder PostgreSQL:
\n>>> print(Blog.objects.filter(title="My Blog").explain())\nSeq Scan on blog (cost=0.00..35.50 rows=10 width=12)\n Filter: (title = 'My Blog'::bpchar)\nUtdata skiljer sig avsevärt mellan olika databaser.
\nexplain() stöds av alla inbyggda databasbackends utom Oracle eftersom en implementering där inte är okomplicerad.
Parametern format ändrar utdataformatet från databasens standardformat, som vanligtvis är textbaserat. PostgreSQL stöder formaten 'TEXT', 'JSON', 'YAML' och 'XML'. MariaDB och MySQL stöder formaten 'TEXT' (även kallat 'TRADITIONAL') och 'JSON'. MySQL 8.0.16+ stöder också ett förbättrat 'TREE'-format, som liknar PostgreSQLs 'TEXT'-utdata och används som standard om det stöds.
Vissa databaser accepterar flaggor som kan ge mer information om frågan. Skicka dessa flaggor som nyckelordsargument. Till exempel: när du använder PostgreSQL:
\n>>> print(Blog.objects.filter(title="My Blog").explain(verbose=True, analyze=True))\nSeq Scan on public.blog (cost=0.00..35.50 rows=10 width=12) (actual time=0.004..0.004 rows=10 loops=1)\n Output: id, title\n Filter: (blog.title = 'My Blog'::bpchar)\nPlanning time: 0.064 ms\nExecution time: 0.058 ms\nPå vissa databaser kan flaggor göra att frågan körs på ett sätt som kan få negativa följder för databasen. Flaggan ANALYZE som stöds av MariaDB, MySQL och PostgreSQL kan till exempel leda till dataändringar om det finns triggers eller om en funktion anropas, även för en fråga av typen SELECT.
Field uppslagningarLink to this heading#Fältuppslag anger huvudvillkoret i en SQL-sats WHERE. De anges som nyckelordsargument till QuerySet-metoderna filter(), exclude() och get().
För en introduktion, se dokumentation om modeller och databasfrågor.
\nDjangos inbyggda lookups listas nedan. Det är också möjligt att skriva custom lookups för modellfält.
\nSom en bekvämlighet när ingen uppslagstyp anges (som i Entry.objects.get(id=14)) antas uppslagstypen vara exact.
exaktLink to this heading#Exakt träff. Om värdet som anges för jämförelse är None tolkas det som SQL NULL (se isnull för mer information). Uppslag efter nyckel och index är undantag: de tolkar i stället None som JSON null.
Exempel:
\nEntry.objects.get(id__exact=14)\nEntry.objects.get(id__exact=None)\nSQL-ekvivalenter:
\nSELECT ... WHERE id = 14;\nSELECT ... WHERE id IS NULL;\niexaktLink to this heading#Exakt matchning utan skiftlägeskänslighet. Om det värde som anges för jämförelse är None tolkas det som en SQL NULL (se isnull` för mer information).
Exempel:
\nBlog.objects.get(name__iexact="beatles blog")\nBlog.objects.get(name__iexact=None)\nSQL-ekvivalenter:
\nSELECT ... WHERE name ILIKE 'beatles blog';\nSELECT ... WHERE name IS NULL;\nObservera att den första frågan kommer att matcha 'Beatles Blog', 'beatles blog', 'BeAtLes BLoG', etc.
innehållerLink to this heading#Case-sensitive containment test.
\nExempel:
\nEntry.objects.get(headline__contains="Lennon")\nSQL-ekvivalent:
\nSELECT ... WHERE headline LIKE '%Lennon%';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nObservera att detta kommer att matcha rubriken 'Lennon hedrad idag' men inte 'lennon hedrad idag'.
ikonerLink to this heading#Case-insensitive containment test.
\nExempel:
\nEntry.objects.get(headline__icontains="Lennon")\nSQL-ekvivalent:
\nSELECT ... WHERE headline ILIKE '%Lennon%';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\n\ninLink to this heading#I en given iterabel; ofta en lista, tupel eller queryset. Det är inte ett vanligt användningsfall, men strängar (som är iterabla) accepteras.
\nExempel:
\nEntry.objects.filter(id__in=[1, 3, 4])\nEntry.objects.filter(headline__in="abc")\nSQL-ekvivalenter:
\nSELECT ... WHERE id IN (1, 3, 4);\nSELECT ... WHERE headline IN ('a', 'b', 'c');\nDu kan också använda en queryset för att dynamiskt utvärdera listan med värden i stället för att tillhandahålla en lista med bokstavliga värden:
\ninner_qs = Blog.objects.filter(name__contains="Cheddar")\nentries = Entry.objects.filter(blog__in=inner_qs)\nDetta queryset kommer att utvärderas som ett subselect-svar:
\nSELECT ... WHERE blog.id IN (SELECT id FROM ... WHERE NAME LIKE '%Cheddar%')\nOm du skickar in en QuerySet som är resultatet av values() eller values_list() som värde till en __in lookup, måste du se till att du bara extraherar ett fält i resultatet. Det här fungerar till exempel (filtrering på bloggnamn):
inner_qs = Blog.objects.filter(name__contains="Ch").values("name")\nentries = Entry.objects.filter(blog__name__in=inner_qs)\nDetta exempel kommer att leda till ett undantag, eftersom den inre frågan försöker extrahera två fältvärden, där endast ett förväntas:
\n# Bad code! Will raise a TypeError.\ninner_qs = Blog.objects.filter(name__contains="Ch").values("name", "id")\nentries = Entry.objects.filter(blog__name__in=inner_qs)\ngtLink to this heading#Större än.
\nExempel:
\nEntry.objects.filter(id__gt=4)\nSQL-ekvivalent:
\nSELECT ... WHERE id > 4;\ngteLink to this heading#Större än eller lika med.
\nltLink to this heading#Mindre än.
\nlteLink to this heading#Mindre än eller lika med.
\nbörjar medLink to this heading#Case-sensitive börjar med.
\nExempel:
\nEntry.objects.filter(headline__startswith="Lennon")\nSQL-ekvivalent:
\nSELECT ... WHERE headline LIKE 'Lennon%';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nSQLite stöder inte skiftlägeskänsliga LIKE-satser; startswith fungerar som istartswith för SQLite.
istartswithLink to this heading#Case-insensitive börjar med.
\nExempel:
\nEntry.objects.filter(headline__istartswith="Lennon")\nSQL-ekvivalent:
\nSELECT ... WHERE headline ILIKE 'Lennon%';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\n\nslutar medLink to this heading#Case-sensitive slutar med.
\nExempel:
\nEntry.objects.filter(headline__endswith="Lennon")\nSQL-ekvivalent:
\nSELECT ... WHERE headline LIKE '%Lennon';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\n\nCase-insensitive slutar med.
\nExempel:
\nEntry.objects.filter(headline__iendswith="Lennon")\nSQL-ekvivalent:
\nSELECT ... WHERE headline ILIKE '%Lennon';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\n\nintervallLink to this heading#Avståndstest (inklusive).
\nExempel:
\nimport datetime\n\nstart_date = datetime.date(2005, 1, 1)\nend_date = datetime.date(2005, 3, 31)\nEntry.objects.filter(pub_date__range=(start_date, end_date))\nSQL-ekvivalent:
\nSELECT ... WHERE pub_date BETWEEN '2005-01-01' and '2005-03-31';\nDu kan använda range överallt där du kan använda BETWEEN i SQL - för datum, siffror och till och med tecken.
datumLink to this heading#För datetime-fält kastas värdet som datum. Tillåter kedjning av ytterligare fältuppslagningar. Tar emot ett datumvärde.
\nExempel:
\nEntry.objects.filter(pub_date__date=datetime.date(2005, 1, 1))\nEntry.objects.filter(pub_date__date__gt=datetime.date(2005, 1, 1))\n(Inget motsvarande SQL-kodfragment ingår för den här sökningen eftersom implementeringen av den relevanta frågan varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras fält till aktuell tidszon före filtrering. Detta kräver tidszonsdefinitioner i databasen.
årLink to this heading#För datum- och datetime-fält, en exakt matchning av år. Tillåter kedjning av ytterligare fältuppslagningar. Tar ett heltalsår.
\nExempel:
\nEntry.objects.filter(pub_date__year=2005)\nEntry.objects.filter(pub_date__year__gte=2005)\nSQL-ekvivalent:
\nSELECT ... WHERE pub_date BETWEEN '2005-01-01' AND '2005-12-31';\nSELECT ... WHERE pub_date >= '2005-01-01';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
iso_yearLink to this heading#För datum- och datetime-fält, en exakt matchning av ISO 8601 veckonummer och år. Tillåter kedjning av ytterligare fältuppslagningar. Tar ett heltalsår.
\nExempel:
\nEntry.objects.filter(pub_date__iso_year=2005)\nEntry.objects.filter(pub_date__iso_year__gte=2005)\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
månadLink to this heading#För datum- och datetime-fält, en exakt matchning av månaden. Tillåter kedjning av ytterligare fältuppslagningar. Tar ett heltal från 1 (januari) till 12 (december).
\nExempel:
\nEntry.objects.filter(pub_date__month=12)\nEntry.objects.filter(pub_date__month__gte=6)\nSQL-ekvivalent:
\nSELECT ... WHERE EXTRACT('month' FROM pub_date) = '12';\nSELECT ... WHERE EXTRACT('month' FROM pub_date) >= '6';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
dagLink to this heading#För datum- och datetime-fält, en exakt matchning av dagen. Tillåter kedjning av ytterligare fältuppslagningar. Tar en heltalsdag.
\nExempel:
\nEntry.objects.filter(pub_date__day=3)\nEntry.objects.filter(pub_date__day__gte=3)\nSQL-ekvivalent:
\nSELECT ... WHERE EXTRACT('day' FROM pub_date) = '3';\nSELECT ... WHERE EXTRACT('day' FROM pub_date) >= '3';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nObservera att detta kommer att matcha alla poster med ett pub_date på den tredje dagen i månaden, t.ex. 3 januari, 3 juli etc.
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
veckaLink to this heading#För datum- och datetime-fält returneras veckonumret (1-52 eller 53) enligt ISO-8601, dvs. veckorna börjar på en måndag och den första veckan innehåller årets första torsdag.
\nExempel:
\nEntry.objects.filter(pub_date__week=52)\nEntry.objects.filter(pub_date__week__gte=32, pub_date__week__lte=38)\n(Inget motsvarande SQL-kodfragment ingår för den här sökningen eftersom implementeringen av den relevanta frågan varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
veckodagLink to this heading#För datum- och datetime-fält, en matchning av ”veckodag”. Tillåter kedjning av ytterligare fältuppslagningar.
\nTar ett heltalsvärde som representerar veckodagen från 1 (söndag) till 7 (lördag).
\nExempel:
\nEntry.objects.filter(pub_date__week_day=2)\nEntry.objects.filter(pub_date__week_day__gte=2)\n(Inget motsvarande SQL-kodfragment ingår för den här sökningen eftersom implementeringen av den relevanta frågan varierar mellan olika databasmotorer)
\nObservera att detta kommer att matcha alla poster med ett pub_date som infaller på en måndag (dag 2 i veckan), oavsett vilken månad eller vilket år det inträffar. Veckodagar är indexerade så att dag 1 är söndag och dag 7 är lördag.
När USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
iso_week_dayLink to this heading#För datum- och datetime-fält, en exakt matchning av veckodag enligt ISO 8601. Tillåter kedjning av ytterligare fältuppslagningar.
\nTar ett heltalsvärde som representerar veckodagen från 1 (måndag) till 7 (söndag).
\nExempel:
\nEntry.objects.filter(pub_date__iso_week_day=1)\nEntry.objects.filter(pub_date__iso_week_day__gte=1)\n(Inget motsvarande SQL-kodfragment ingår för den här sökningen eftersom implementeringen av den relevanta frågan varierar mellan olika databasmotorer)
\nObservera att detta kommer att matcha alla poster med ett pub_date som infaller på en måndag (dag 1 i veckan), oavsett vilken månad eller vilket år det inträffar. Veckodagar är indexerade så att dag 1 är måndag och dag 7 är söndag.
När USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
kvartalLink to this heading#För datum- och datetime-fält, en matchning av ”kvartal i året”. Tillåter kedjning av ytterligare fältuppslagningar. Tar ett heltalsvärde mellan 1 och 4 som representerar kvartalet i året.
\nExempel för att hämta poster under andra kvartalet (1 april till 30 juni):
\nEntry.objects.filter(pub_date__quarter=2)\n(Inget motsvarande SQL-kodfragment ingår för den här sökningen eftersom implementeringen av den relevanta frågan varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
tidLink to this heading#För datetime-fält kastas värdet som tid. Tillåter kedjning av ytterligare fältuppslagningar. Tar emot ett värde av datetime.time.
Exempel:
\nEntry.objects.filter(pub_date__time=datetime.time(14, 30))\nEntry.objects.filter(pub_date__time__range=(datetime.time(8), datetime.time(17)))\n(Inget motsvarande SQL-kodfragment ingår för den här sökningen eftersom implementeringen av den relevanta frågan varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras fält till aktuell tidszon före filtrering. Detta kräver tidszonsdefinitioner i databasen.
timmeLink to this heading#För datetime- och time-fält, en exakt matchning av timmar. Tillåter kedjning av ytterligare fältuppslagningar. Tar ett heltal mellan 0 och 23.
\nExempel:
\nEvent.objects.filter(timestamp__hour=23)\nEvent.objects.filter(time__hour=5)\nEvent.objects.filter(timestamp__hour__gte=12)\nSQL-ekvivalent:
\nSELECT ... WHERE EXTRACT('hour' FROM timestamp) = '23';\nSELECT ... WHERE EXTRACT('hour' FROM time) = '5';\nSELECT ... WHERE EXTRACT('hour' FROM timestamp) >= '12';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
minutLink to this heading#För datetime- och time-fält, en exakt minutmatchning. Tillåter kedjning av ytterligare fältuppslagningar. Tar ett heltal mellan 0 och 59.
\nExempel:
\nEvent.objects.filter(timestamp__minute=29)\nEvent.objects.filter(time__minute=46)\nEvent.objects.filter(timestamp__minute__gte=29)\nSQL-ekvivalent:
\nSELECT ... WHERE EXTRACT('minute' FROM timestamp) = '29';\nSELECT ... WHERE EXTRACT('minute' FROM time) = '46';\nSELECT ... WHERE EXTRACT('minute' FROM timestamp) >= '29';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
sekundLink to this heading#För datetime- och time-fält, en exakt andra matchning. Tillåter kedjning av ytterligare fältuppslagningar. Tar ett heltal mellan 0 och 59.
\nExempel:
\nEvent.objects.filter(timestamp__second=31)\nEvent.objects.filter(time__second=2)\nEvent.objects.filter(timestamp__second__gte=31)\nSQL-ekvivalent:
\nSELECT ... WHERE EXTRACT('second' FROM timestamp) = '31';\nSELECT ... WHERE EXTRACT('second' FROM time) = '2';\nSELECT ... WHERE EXTRACT('second' FROM timestamp) >= '31';\n(Den exakta SQL-syntaxen varierar mellan olika databasmotorer)
\nNär USE_TZ är True konverteras datetime-fält till den aktuella tidszonen före filtrering. Detta kräver tidszonsdefinitioner i databasen.
isnullLink to this heading#Tar antingen True eller False, vilket motsvarar SQL-frågorna IS NULL respektive IS NOT NULL.
Exempel:
\nEntry.objects.filter(pub_date__isnull=True)\nSQL-ekvivalent:
\nSELECT ... WHERE pub_date IS NULL;\nregexLink to this heading#Skiftlägeskänslig matchning med reguljärt uttryck.
\nSyntaxen för reguljära uttryck är den som används i databasens backend. När det gäller SQLite, som inte har något inbyggt stöd för reguljära uttryck, tillhandahålls denna funktion av en (Python) användardefinierad REGEXP-funktion, och syntaxen för reguljära uttryck är därför den som används i Pythons modul re.
Exempel:
\nEntry.objects.get(title__regex=r"^(An?|The) +")\nSQL-ekvivalenter:
\nSELECT ... WHERE title REGEXP BINARY '^(An?|The) +'; -- MySQL\n\nSELECT ... WHERE REGEXP_LIKE(title, '^(An?|The) +', 'c'); -- Oracle\n\nSELECT ... WHERE title ~ '^(An?|The) +'; -- PostgreSQL\n\nSELECT ... WHERE title REGEXP '^(An?|The) +'; -- SQLite\nDet rekommenderas att använda råa strängar (t.ex. r'foo' i stället för 'foo') för att skicka in syntaxen för reguljära uttryck.
iregexLink to this heading#Matchning av reguljära uttryck utan skiftlägeskänslighet.
\nExempel:
\nEntry.objects.get(title__iregex=r"^(an?|the) +")\nSQL-ekvivalenter:
\nSELECT ... WHERE title REGEXP '^(an?|the) +'; -- MySQL\n\nSELECT ... WHERE REGEXP_LIKE(title, '^(an?|the) +', 'i'); -- Oracle\n\nSELECT ... WHERE title ~* '^(an?|the) +'; -- PostgreSQL\n\nSELECT ... WHERE title REGEXP '(?i)^(an?|the) +'; -- SQLite\nDjango tillhandahåller följande aggregeringsfunktioner i modulen django.db.models. För detaljer om hur du använder dessa aggregeringsfunktioner, se ämnesguiden om aggregering. Se Aggregate-dokumentationen för att lära dig hur du skapar dina aggregat.
Alla aggregat har följande parametrar gemensamt:
\nuttryckLink to this heading#Strängar som refererar till fält i modellen, transformationer av fältet eller frågeuttryck.
\nutgångsfältLink to this heading#Ett valfritt argument som representerar modellfältet i returvärdet
\n\nfilterLink to this heading#Ett valfritt Q-objekt som används för att filtrera de rader som aggregeras.
\nSe Villkorlig aggregering och Filtrering av anteckningar för exempel på användning.
\nstandardLink to this heading#Ett valfritt argument som gör det möjligt att ange ett värde som ska användas som standardvärde när frågeuppsättningen (eller grupperingen) inte innehåller några poster.
\n**extraLink to this heading#Nyckelord som kan ge extra kontext för den SQL som genereras av aggregatet.
\nAnyValueLink to this heading#Returnerar ett godtyckligt värde från indatavärden som inte är null.
\nStandardalias: <field>__anyvalue
Typ av retur: samma som input-fältet, eller output_field om det anges. Om queryset eller grupperingen är tom returneras default.
Exempel på användning:
\n>>> # Get average rating for each year along with a sample headline\n>>> # from that year.\n>>> from django.db.models import AnyValue, Avg, F, Q\n>>> sample_headline = AnyValue("headline")\n>>> Entry.objects.values(\n... pub_year=F("pub_date__year"),\n... ).annotate(\n... avg_rating=Avg("rating"),\n... sample_headline=sample_headline,\n... )\n\n>>> # Get a sample headline from each year with rating greater than 4.5.\n>>> sample_headline = AnyValue(\n... "headline",\n... filter=Q(rating__gt=4.5),\n... )\n>>> Entry.objects.values(\n... pub_year=F("pub_date__year"),\n... ).annotate(\n... avg_rating=Avg("rating"),\n... sample_headline=sample_headline,\n... )\nStöds i SQLite, MySQL, Oracle och PostgreSQL 16+.
\n\nAvgLink to this heading#Returnerar medelvärdet av det angivna uttrycket, som måste vara numeriskt om du inte anger ett annat output_field.
Standardalias: <field>__avg
Typ av retur: float om indata är int, annars samma som indatafältet, eller output_field om det anges. Om queryset eller grupperingen är tom returneras default.
Valfritt. Om distinct=True returnerar Avg medelvärdet av unika värden. Detta är SQL-ekvivalenten till AVG(DISTINCT <field>). Standardvärdet är False.
Bit ochLink to this heading#Returnerar ett int av bitvis AND av alla icke-null värden, eller default om alla värden är null.
Parametern default stöds inte i MariaDB, MySQL och Oracle.
BitOrLink to this heading#Returnerar ett int av det bitvisa OR av alla icke-null indatavärden, eller default om alla värden är null.
Parametern default stöds inte i MariaDB, MySQL och Oracle.
BitXorLink to this heading#Returnerar ett int med bitvis XOR för alla indata som inte är null, eller default om alla värden är null.
Parametern default stöds inte i MariaDB, MySQL och Oracle.
CountLink to this heading#Returnerar antalet objekt som är relaterade med hjälp av det angivna uttrycket. Count('*') är likvärdigt med SQL-uttrycket COUNT(*).
Standardalias: <field>__count
Typ av retur: int
Valfritt. Om distinct=True, kommer räkningen endast att omfatta unika instanser. Detta är SQL-ekvivalenten till COUNT(DISTINCT <field>). Standardvärdet är False.
MaxLink to this heading#Returnerar det maximala värdet för det angivna uttrycket.
\nStandardalias: <field>__max
Typ av retur: samma som input-fältet, eller output_field om det anges. Om queryset eller grupperingen är tom returneras default.
MinLink to this heading#Returnerar det lägsta värdet för det angivna uttrycket.
\nStandardalias: <field>__min
Typ av retur: samma som input-fältet, eller output_field om det anges. Om queryset eller grupperingen är tom returneras default.
StdDevLink to this heading#Returnerar standardavvikelsen för data i det angivna uttrycket.
\nStandardalias: <field>__stddev
Typ av retur: float om indata är int, annars samma som indatafältet, eller output_field om det anges. Om queryset eller grupperingen är tom returneras default.
Valfritt. Som standard returnerar StdDev populationens standardavvikelse. Men om sample=True, kommer returvärdet att vara standardavvikelsen för urvalet.
SummaLink to this heading#Beräknar summan av alla värden för det angivna uttrycket.
\nStandardalias: <field>__sum
Typ av retur: samma som input-fältet, eller output_field om det anges. Om queryset eller grupperingen är tom returneras default.
Valfritt. Om distinct=True returnerar Sum summan av unika värden. Detta är SQL-ekvivalenten till SUM(DISTINCT <field>). Standardvärdet är False.
VariansLink to this heading#Returnerar variansen för data i det angivna uttrycket.
\nStandardalias: <field>__variance
Typ av retur: float om indata är int, annars samma som indatafältet, eller output_field om det anges. Om queryset eller grupperingen är tom returneras default.
Valfritt. Som standard returnerar Variance populationsvariansen. Men om sample=True kommer returvärdet att vara urvalsvariansen.
StringAggLink to this heading#Returnerar indatavärdena sammankopplade till en sträng, åtskilda av strängen delimiter eller default om det inte finns några värden.
Standardalias: <field>__stringagg
Returtyp: string eller output_field om den anges. Om frågeuppsättningen eller grupperingen är tom returneras default.
Ett Value eller uttryck som representerar strängen som ska separera vart och ett av värdena. Till exempel Value(","). (I SQLite är avgränsaren Value(",") den enda som är kompatibel med distinct=True.)