Django gives you two ways of performing raw SQL queries: you can use\nManager.raw() to perform raw queries and return model instances, or\nyou can avoid the model layer entirely and execute custom SQL directly.
raw() マネージャメソッドは素の SQL 文を処理してモデルのインスタンスを返させる場合に利用できます:
This method takes a raw SQL query, executes it, and returns a\ndjango.db.models.query.RawQuerySet instance. This RawQuerySet instance\ncan be iterated over like a normal QuerySet to\nprovide object instances.
例を示す事で最も簡単に説明できます。以下のモデルについて考えてください:
\nclass Person(models.Model):\n first_name = models.CharField(...)\n last_name = models.CharField(...)\n birth_date = models.DateField(...)\nYou could then execute custom SQL like so:
\n>>> for p in Person.objects.raw("SELECT * FROM myapp_person"):\n... print(p)\n...\nJohn Smith\nJane Jones\nThis example isn't very exciting -- it's exactly the same as running\nPerson.objects.all(). However, raw() has a bunch of other options that\nmake it very powerful.
raw() は自動的にクエリのフィールドをモデルのフィールドにマップします。
The order of fields in your query doesn't matter. In other words, both\nof the following queries work identically:
\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")\nMatching is done by name. This means that you can use SQL's AS clauses to\nmap fields in the query to model fields. So if you had some other table that\nhad Person data in it, you could easily map it into Person instances:
>>> Person.objects.raw(\n... """\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... )\n名称が一致している限り、そのモデルのインスタンスは適切に生成されます。
\nAlternatively, you can map fields in the query to model fields using the\ntranslations argument to raw(). This is a dictionary mapping names of\nfields in the query to names of fields on the model. For example, the above\nquery could also be written:
>>> 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() supports indexing, so if you need only the first result you can\nwrite:
>>> first_person = Person.objects.raw("SELECT * FROM myapp_person")[0]\nHowever, the indexing and slicing are not performed at the database level. If\nyou have a large number of Person objects in your database, it is more\nefficient to limit the query at the SQL level:
>>> first_person = Person.objects.raw("SELECT * FROM myapp_person LIMIT 1")[0]\nFields may also be left out:
\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\nFrom outward appearances, this looks like the query has retrieved both\nthe first name and last name. However, this example actually issued 3\nqueries. Only the first names were retrieved by the raw() query -- the\nlast names were both retrieved on demand when they were printed.
There is only one field that you can't leave out - the primary key\nfield. Django uses the primary key to identify model instances, so it\nmust always be included in a raw query. A\nFieldDoesNotExist exception will be raised if\nyou forget to include the primary key.
You can also execute queries containing fields that aren't defined on the\nmodel. For example, we could use PostgreSQL's age() function to get a list\nof people with their ages calculated by the database:
\n>>> people = Person.objects.raw("SELECT *, age(birth_date) AS age FROM myapp_person")\n>>> for p in people:\n... print("%s is %s." % (p.first_name, p.age))\n...\nJohn is 37.\nJane is 42.\n...\nYou can often avoid using raw SQL to compute annotations by instead using a\nFunc() expression.
\nraw() にパラメータを渡すLink to this heading#If you need to perform parameterized queries, you can use the params\nargument to raw():
>>> lname = "Doe"\n>>> Person.objects.raw("SELECT * FROM myapp_person WHERE last_name = %s", [lname])\nparams is a list or dictionary of parameters. You'll use %s\nplaceholders in the query string for a list, or %(key)s\nplaceholders for a dictionary (where key is replaced by a\ndictionary key), regardless of your database engine. Such placeholders will be\nreplaced with parameters from the params argument.
Manager.raw() でも要求を満たせない場合があります:きれいにモデルにマップできないクエリを扱ったり、UPDATE、 INSERT あるいは DELETE を直接実行したりする必要が有るかもしれません。
こういったケースでは、モデル層を完全に迂回してデータベースにいつでも直接アクセスできます。
\ndjango.db.connection オブジェクトがデフォルトのデータベース接続に対応しています。そのデータベース接続を利用するには、カーソルオブジェクトを取得するため connection.cursor() を呼び出してください。続いて、cursor.execute(sql, [params]) を呼び出して SQL を実行した後 cursor.fetchone() もしくは cursor.fetchall() で結果の行を取得します。
例:
\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\nTo protect against SQL injection, you must not include quotes around the %s\nplaceholders in the SQL string.
もしリテラルなパーセント記号をクエリ中で使いたい場合、パラメータを渡す際に二重に記述する必要が有る事に注意してください:
\ncursor.execute("SELECT foo FROM bar WHERE baz = '30%'")\ncursor.execute("SELECT foo FROM bar WHERE baz = '30%%' AND id = %s", [self.id])\n2 つ以上のデータベース を利用している場合、特定の接続(とカーソル)を取得するのに django.db.connections を利用できます。django.db.connections はその別名を指定する事で特定の接続を得られる、辞書に似たオブジェクトです:
from django.db import connections\n\nwith connections["my_db_alias"].cursor() as cursor:\n # Your code here\n ...\nデフォルトでは、Python データベース API は返す結果にフィールド名を含まず、つまり 辞書 でなく、 リスト の値として結果を返します。処理能力とメモリを少々利用して、次のような処理を用いる事で結果を 辞書 として得られます:
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()]\n別の選択肢は Python 標準ライブラリに含まれる collections.namedtuple() を利用する事です。namedtuple は属性を指定して値へのアクセスが可能なタプルに似たオブジェクトです; 加えてインデックスが利用でき、イテレート可能でもあります。取得した結果は不変であり属性名もしくはインデックスでアクセスできて便利です:
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()]\nThe dictfetchall() and namedtuplefetchall() examples assume unique\ncolumn names, since a cursor cannot distinguish columns from different tables.
Here is an example of the difference between the three:
\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 と cursor の実装は PEP 249 に規定された Python DB-API の基準にほぼ完全に準拠しています — トランザクション操作 は例外となります。
Python DB-API に精通していない場合、cursor.execute() 内の SQL 文には直接値を追加せずに、"%s" というプレースホルダーを利用する事に注意してください。この手法を用いる事で、内部で動作しているデータベースライブラリは自動的に必要に応じて値のエスケープを行ってくれます。
加えて Django はプレースホルダーとして Python に内蔵された SQLite モジュールで用いられる "?" でなく "%s" を期待して動作する事にも注意してください。これは全体の調和と健全性のためです。
コンテキストマネージャとしてのカーソルの利用:
\nwith connection.cursor() as c:\n c.execute(...)\nこれは以下と同じです:
\nc = connection.cursor()\ntry:\n c.execute(...)\nfinally:\n c.close()\nCalls a database stored procedure with the given name. A sequence\n(params) or dictionary (kparams) of input parameters may be\nprovided. Most databases don't support kparams. Of Django's built-in\nbackends, only Oracle supports it.
For example, given this stored procedure in an Oracle database:
\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;\nThis will call it:
\nwith connection.cursor() as cursor:\n cursor.callproc("test_procedure", [1, "test"])\n