Django gives you three ways of performing raw SQL queries: you can embed raw\nSQL fragments into ORM queries using\nRawSQL (see Raw SQL fragments),\nuse Manager.raw() to perform raw queries and return model instances,\nor avoid the model layer entirely and execute custom SQL directly.
In some cases, you may need to embed raw SQL fragments directly into ORM\nqueries — for example, in annotate() or\nfilter() calls. Use Func()\nexpressions for calling database functions across\nbackends, or\nRawSQL for arbitrary parameterized SQL\nfragments.
Hanteringsmetoden raw() kan användas för att utföra råa SQL-frågor som returnerar modellinstanser:
Den här metoden tar en rå SQL-fråga, kör den och returnerar en django.db.models.query.RawQuerySet-instans. Denna RawQuerySet-instans kan itereras över som en normal QuerySet för att tillhandahålla objektinstanser.
Detta illustreras bäst med ett exempel. Anta att du har följande modell:
\nclass Person(models.Model):\n first_name = models.CharField(...)\n last_name = models.CharField(...)\n birth_date = models.DateField(...)\nDu kan sedan köra anpassad SQL på följande sätt:
\n>>> for p in Person.objects.raw("SELECT * FROM myapp_person"):\n... print(p)\n...\nJohn Smith\nJane Jones\nDet här exemplet är inte särskilt spännande - det är exakt samma sak som att köra Person.objects.all(). Men raw() har en massa andra alternativ som gör den mycket kraftfull.
raw() mappar automatiskt fält i frågan till fält i modellen.
Ordningen på fälten i din fråga spelar ingen roll. Med andra ord fungerar båda följande frågor på samma sätt:
\n>>> Person.objects.raw("SELECT id, first_name, last_name, birth_date FROM myapp_person")\n>>> Person.objects.raw("SELECT last_name, birth_date, first_name, id FROM myapp_person")\nMatchningen görs med hjälp av namn. Det innebär att du kan använda SQL:s AS-klausuler för att mappa fält i frågan till modellfält. Så om du hade någon annan tabell som hade Person-data i den, kan du enkelt mappa den till Person-instanser:
>>> Person.objects.raw("""\n... SELECT first AS first_name,\n... last AS last_name,\n... bd AS birth_date,\n... pk AS id,\n... FROM some_other_table\n... """)\n...\nSå länge namnen stämmer överens kommer modellinstanserna att skapas på rätt sätt.
\nAlternativt kan du mappa fält i frågan till modellfält med hjälp av argumentet translations till raw(). Detta är en ordbok som mappar namn på fält i frågan till namn på fält i modellen. Till exempel kan ovanstående fråga också skrivas:
>>> name_map = {"first": "first_name", "last": "last_name", "bd": "birth_date", "pk": "id"}\n>>> Person.objects.raw("SELECT * FROM some_other_table", translations=name_map)\nraw() stöder indexering, så om du bara behöver det första resultatet kan du skriva:
>>> first_person = Person.objects.raw("SELECT * FROM myapp_person")[0]\nIndexeringen och skivningen utförs dock inte på databasnivå. Om du har ett stort antal Person-objekt i din databas är det mer effektivt att begränsa frågan på SQL-nivå:
>>> first_person = Person.objects.raw("SELECT * FROM myapp_person LIMIT 1")[0]\nFält kan också utelämnas:
\n>>> people = Person.objects.raw("SELECT id, first_name FROM myapp_person")\nThe Person objects returned by this query will be deferred model instances\n(see defer()). This means that the\nfields that are omitted from the query will be loaded on demand. For example:
>>> for p in Person.objects.raw("SELECT id, first_name FROM myapp_person"):\n... print(\n... p.first_name, # This will be retrieved by the original query\n... p.last_name, # This will be retrieved on demand\n... )\n...\nJohn Smith\nJane Jones\nUtåt sett ser det ut som om frågan har hämtat både förnamnet och efternamnet. Men i det här exemplet ställdes faktiskt tre frågor. Endast förnamnen hämtades av raw()-frågan - efternamnen hämtades båda på begäran när de skrevs ut.
Det finns bara ett fält som du inte kan utelämna - fältet för primärnyckeln. Django använder primärnyckeln för att identifiera modellinstanser, så den måste alltid inkluderas i en rå fråga. Ett FieldDoesNotExist undantag kommer att uppstå om du glömmer att inkludera den primära nyckeln.
raw()Link to this heading#Om du behöver utföra parametriserade frågor kan du använda argumentet params till raw():
>>> lname = "Doe"\n>>> Person.objects.raw("SELECT * FROM myapp_person WHERE last_name = %s", [lname])\nparams är en lista eller en ordbok med parametrar. Du använder %s platshållare i frågesträngen för en lista, eller %(key)s platshållare för en ordbok (där key ersätts av en ordboksnyckel), oavsett vilken databasmotor du använder. Sådana platshållare kommer att ersättas med parametrar från argumentet params.
Ibland räcker inte ens Manager.raw(): du kan behöva utföra frågor som inte mappar rent till modeller, eller direkt köra UPDATE, INSERT eller DELETE-frågor.
I dessa fall kan du alltid komma åt databasen direkt och helt undvika modellagret.
\nObjektet django.db.connection representerar standardanslutningen till databasen. För att använda databasanslutningen, anropa connection.cursor() för att få ett cursor-objekt. Anropa sedan cursor.execute(sql, [params]) för att köra SQL och cursor.fetchone() eller cursor.fetchall() för att returnera de resulterande raderna.
Till exempel:
\nfrom django.db import connection\n\n\ndef my_custom_sql(self):\n with connection.cursor() as cursor:\n cursor.execute("UPDATE bar SET foo = 1 WHERE baz = %s", [self.baz])\n cursor.execute("SELECT foo FROM bar WHERE baz = %s", [self.baz])\n row = cursor.fetchone()\n\n return row\nFör att skydda mot SQL-injektion får du inte inkludera citattecken runt platshållarna %s i SQL-strängen.
Observera att om du vill inkludera bokstavliga procenttecken i frågan måste du dubbla dem i det fall du skickar parametrar:
\ncursor.execute("SELECT foo FROM bar WHERE baz = '30%'")\ncursor.execute("SELECT foo FROM bar WHERE baz = '30%%' AND id = %s", [self.id])\nOm du använder fler än en databas kan du använda django.db.connections för att hämta anslutningen (och markören) för en specifik databas. django.db.connections är ett ordboksliknande objekt som gör att du kan hämta en specifik anslutning med hjälp av dess alias:
from django.db import connections\n\nwith connections["my_db_alias"].cursor() as cursor:\n # Your code here\n ...\nSom standard kommer Python DB API att returnera resultat utan deras fältnamn, vilket innebär att du får en ”lista” med värden, snarare än ett ”dict”. Med en liten prestanda- och minneskostnad kan du returnera resultat som en dict genom att använda något liknande detta:
def dictfetchall(cursor):\n """\n Return all rows from a cursor as a dict.\n Assume the column names are unique.\n """\n columns = [col[0] for col in cursor.description]\n return [dict(zip(columns, row)) for row in cursor.fetchall()]\nEtt annat alternativ är att använda collections.namedtuple() från Pythons standardbibliotek. En namedtuple är ett tuple-liknande objekt som har fält som är tillgängliga genom attributuppslagning; det är också indexerbart och itererbart. Resultaten är oföränderliga och tillgängliga med fältnamn eller index, vilket kan vara användbart:
from collections import namedtuple\n\n\ndef namedtuplefetchall(cursor):\n """\n Return all rows from a cursor as a namedtuple.\n Assume the column names are unique.\n """\n desc = cursor.description\n nt_result = namedtuple("Result", [col[0] for col in desc])\n return [nt_result(*row) for row in cursor.fetchall()]\nExemplen dictfetchall() och namedtuplefetchall() förutsätter unika kolumnnamn, eftersom en markör inte kan skilja på kolumner från olika tabeller.
Här är ett exempel på skillnaden mellan de tre:
\n>>> cursor.execute("SELECT id, parent_id FROM test LIMIT 2")\n>>> cursor.fetchall()\n((54360982, None), (54360880, None))\n\n>>> cursor.execute("SELECT id, parent_id FROM test LIMIT 2")\n>>> dictfetchall(cursor)\n[{'parent_id': None, 'id': 54360982}, {'parent_id': None, 'id': 54360880}]\n\n>>> cursor.execute("SELECT id, parent_id FROM test LIMIT 2")\n>>> results = namedtuplefetchall(cursor)\n>>> results\n[Result(id=54360982, parent_id=None), Result(id=54360880, parent_id=None)]\n>>> results[0].id\n54360982\n>>> results[0][0]\n54360982\nconnection och cursor implementerar mestadels standard Python DB-API som beskrivs i PEP 249 - förutom när det gäller transaktionshantering.
Om du inte är bekant med Python DB-API, notera att SQL-satsen i cursor.execute() använder platshållare, "%s", snarare än att lägga till parametrar direkt i SQL. Om du använder den här tekniken kommer det underliggande databasbiblioteket automatiskt att escape dina parametrar vid behov.
Observera också att Django förväntar sig platshållaren "%s", inte platshållaren "?", som används av SQLite Python-bindningar. Detta är för konsekvensens och sanitetens skull.
Använda en markör som kontexthanterare:
\nwith connection.cursor() as c:\n c.execute(...)\när likvärdig med:
\nc = connection.cursor()\ntry:\n c.execute(...)\nfinally:\n c.close()\nAnropar en databaslagrad procedur med det angivna namnet. En sekvens (params) eller ett lexikon (kparams) med inparametrar kan anges. De flesta databaser stöder inte kparams. Av Djangos inbyggda backends är det bara Oracle som stöder det.
Till exempel, med den här lagrade proceduren i en Oracle-databas:
\nCREATE PROCEDURE "TEST_PROCEDURE"(v_i INTEGER, v_text NVARCHAR2(10)) AS\n p_i INTEGER;\n p_text NVARCHAR2(10);\nBEGIN\n p_i := v_i;\n p_text := v_text;\n ...\nEND;\nDetta kommer att kalla det:
\nwith connection.cursor() as cursor:\n cursor.callproc("test_procedure", [1, "test"])\n