一度 データモデル を作成すれば、Django はデータオブジェクトの作成、取得、更新および削除を行えるようにデータベースを抽象化した API を自動的に提供します。本ドキュメントではこの API をどのように用いるかを説明します。多様なモデル探索オプション全てに関する詳細については データモデルの項目 を参照ください。
\n本項( および参照する文章 )では、以下に定義されたウェブログアプリケーションを構成するモデル定義を利用します:
\nfrom django.db import models\n\nclass Blog(models.Model):\n name = models.CharField(max_length=100)\n tagline = models.TextField()\n\n def __str__(self): # __unicode__ on Python 2\n return self.name\n\nclass Author(models.Model):\n name = models.CharField(max_length=200)\n email = models.EmailField()\n\n def __str__(self): # __unicode__ on Python 2\n return self.name\n\nclass Entry(models.Model):\n blog = models.ForeignKey(Blog, on_delete=models.CASCADE)\n headline = models.CharField(max_length=255)\n body_text = models.TextField()\n pub_date = models.DateField()\n mod_date = models.DateField()\n authors = models.ManyToManyField(Author)\n n_comments = models.IntegerField()\n n_pingbacks = models.IntegerField()\n rating = models.IntegerField()\n\n def __str__(self): # __unicode__ on Python 2\n return self.headline\nデータベースのテーブル上のデータを Python オブジェクトに対応付けるため、 Django は直観的なシステムを利用しています: 1 つのモデルクラスが 1 つのデータベーステーブルに対応し、そのモデルクラスの 1 インスタンスが対応するデータベーステーブルの特定のレコードに対応します。
\nオブジェクトを生成するためには、作成するモデルのクラスにキーワード引数を渡してインスタンス化し、そのデータをデータベースに保存するために save() を呼び出します。
モデル定義が mysite/blog/models.py というファイル内に存在すると仮定すると、利用例は以下のようになります:
>>> from blog.models import Blog\n>>> b = Blog(name='Beatles Blog', tagline='All the latest Beatles news.')\n>>> b.save()\nこの例では内部で INSERT SQL 文が処理されます。明示的に save() を呼ぶまで Django はデータベースを操作しません。
save() メソッドは値を返しません。
既にデータベース上に存在する 1 つのオブジェクトに対する変更を保存するには、 save() を利用します。
既にデータベースに保存されている Blog のインスタンスとして b5 が与えられたとして、次の例ではその name を変更してデータベースのレコードを更新します:
>>> b5.name = 'New name'\n>>> b5.save()\nこの例では内部で UPDATE SQL 文が処理されます。明示的に save() が呼ばれるまで Django はデータベースを操作しません。
ForeignKey と ManyToManyField フィールドを扱うLink to this heading#ForeignKey フィールドに対する更新は通常のフィールドに対する更新と完全に同じです -- 単に対象とするフィールドに適した型のオブジェクトを入力するだけです。以下の例では Entry のインスタンスである entry の blog 属性を更新します、 Entry および Blog のインスタンスは、データベースにすでに保存されているものとします (したがって、以下のように取得できます)。
>>> from blog.models import Blog, Entry\n>>> entry = Entry.objects.get(pk=1)\n>>> cheese_blog = Blog.objects.get(name="Cheddar Talk")\n>>> entry.blog = cheese_blog\n>>> entry.save()\nManyToManyField に対する更新は通常のフィールド更新とは少々異なっています -- リレーションのためレコードを追加するには add() メソッドを対象となるフィールドに対して用います。以下の例では entry オブジェクトに Author のインスタンス joe を追加します。
>>> from blog.models import Author\n>>> joe = Author.objects.create(name="Joe")\n>>> entry.authors.add(joe)\nManyToManyField に対して複数のレコードを一度に追加するには、add() 呼び出し時に複数の引数を次の例のように含めます:
>>> john = Author.objects.create(name="John")\n>>> paul = Author.objects.create(name="Paul")\n>>> george = Author.objects.create(name="George")\n>>> ringo = Author.objects.create(name="Ringo")\n>>> entry.authors.add(john, paul, george, ringo)\nもし間違った型のオブジェクトを設定もしくは追加しようとすれば Django はエラーを発生させます。
\nデータベースからオブジェクトを取得するには、モデルクラスの Manager から QuerySet を作ります。
QuerySet はデータベース上のオブジェクトの集合を表しています。多数の フィルター を持つことができます。フィルターは与えられたパラメータに基づいてクエリの検索結果を絞り込みます。SQL 文においては、 QuerySet は SELECT 句、フィルターは WHERE や LIMIT のような絞り込みに用いる句に対応しています。
モデルの Manager を用いることで QuerySet を取得します。各モデルは少なくとも一つの Manager を持ち、デフォルトでは objects という名前を持ちます。以下のようにモデルクラスから直接アクセスしてください。
>>> Blog.objects\n<django.db.models.manager.Manager object at ...>\n>>> b = Blog(name='Foo', tagline='Bar')\n>>> b.objects\nTraceback:\n ...\nAttributeError: "Manager isn't accessible via Blog instances."\nManager はモデルの QuerySet の主な取得元になります。たとえば、 Blog.objects.all() はデータベース内の Blog オブジェクト全てを含んだ QuerySet を返します。
テーブルからオブジェクトを取得する方法で最も簡単なのは、すべてのオブジェクトを取得することです。それには Manager に対して all() メソッドを呼びます。
>>> all_entries = Entry.objects.all()\nall() が返す QuerySet には、データベーステーブルのすべてのオブジェクトが含まれています。しかし、ふつう必要になるのはオブジェクト全体の集合ではなく、その部分集合でしょう。
そのような部分集合を作るには、条件フィルタを追加して最初の QuerySet を絞り込みます。 QuerySet を絞り込む代表的な方法として次の2つのものがあります。
filter(**kwargs)与えられた検索パラメータにマッチする新しい QuerySet を返します。
exclude(**kwargs)与えられた検索パラメータにマッチ しない 新しい QuerySet を返します。
検索パラメータ (上の関数定義における **kwargs ) は、以下の Field lookups で説明するフォーマットに従わなければなりません。
たとえば、2006年以降のブログエントリーの QuerySet を取得するには、 filter() を次のように使用します。
Entry.objects.filter(pub_date__year=2006)\nデフォルトの manager クラスの場合、これは次のコードと等価です。
\nEntry.objects.all().filter(pub_date__year=2006)\n絞り込みを行った QuerySet の結果自体も QuerySet です。そのため、複数の絞り込みをチェーンすることが可能です。たとえば、次のように書くことができます。
>>> Entry.objects.filter(\n... headline__startswith='What'\n... ).exclude(\n... pub_date__gte=datetime.date.today()\n... ).filter(\n... pub_date__gte=datetime.date(2005, 1, 30)\n... )\nこれはデータベース内のすべてのエントリーを含む QuerySet をとり、フィルターを追加し、除外フィルターを追加し、さらにもう1つのフィルターを追加しています。最終的な結果は、"What" で始まるヘッドラインを持ち、2005年1月30日から今日までに公開されたすべてのエントリーを含んだ QuerySet となります。
QuerySet はユニークLink to this heading#QuerySet に対して絞り込みを適用するごとに、前の QuerySet から独立した完全に新しい QuerySet が作られます。絞り込みごとに独立した QuerySet が作られるため、保存したり何度も再利用したりできます。
実装例:
\n>>> q1 = Entry.objects.filter(headline__startswith="What")\n>>> q2 = q1.exclude(pub_date__gte=datetime.date.today())\n>>> q3 = q1.filter(pub_date__gte=datetime.date.today())\nこれら3つの QuerySets は独立しています。1番目は基本の QuerySet で、"What" で始まるヘッドラインを持つ全てのエントリーを含みます。2番めは1番目の部分集合で、 pub_date が今日または未来の日付であるレコードを除外する追加条件を持ちます。3番目も1番目の部分集合で、 pub_date が今日または未来の日付であるレコードだけを選択する追加条件を持ちます。1番目の QuerySet (q1) は、絞り込みの過程において何ら影響を受けません。
QuerySet は遅延評価されるLink to this heading#QuerySets は遅延評価されます。 QuerySet を作る行為はいかなるデータベースも引き起こしません。たとえあなたが1日中フィルターのスタックを積み上げたとしても、 QuerySet が 評価 されるまでは、Django は実際にはクエリを実行しません。次の例を見てください。
>>> q = Entry.objects.filter(headline__startswith="What")\n>>> q = q.filter(pub_date__lte=datetime.date.today())\n>>> q = q.exclude(body_text__icontains="food")\n>>> print(q)\nこの例ではデータベースに3回アクセスしているように見えますが、実際にアクセスしているのは、最終行 (print(q)) での1回だけです。一般に、 QuerySet の結果は、明示的に要求するまでデータベースから取得されません。取得するように要求した時点で、 QuerySet は 評価 され、データベースへのアクセスが発生します。評価が起こる正確なタイミングの詳細については、 When QuerySets are evaluated を参照してください。
get() を用いて1つのオブジェクトを取得するLink to this heading#filter() は、たとえクエリーにマッチしたのが1つのオブジェクトだけだったとしても、常に QuerySet を返します。この場合、 QuerySet には1つの要素だけが含まれることになります。
クエリーにマッチするのは1つのオブジェクトだけだと分かっている場合、 Manager の get() メソッドを呼べば、そのオブジェクトが直接返されます。
>>> one_entry = Entry.objects.get(pk=1)\nfilter() と同じように、 get() には任意のクエリー表現が使用できます。 繰り返しますが、詳しくはあとで説明する Field lookups を見てください。
get() と filter() を [0] でスライスすることには、次のような違いがあることに注意してください。クエリにマッチする結果が存在しない場合、 get() は DoesNotExist 例外を起こします。この例外はクエリーが実行されるモデルクラスの属性です。たとえば上のコードでは、1というプライマリーキーを持つ Entry オブジェクトがなければ、Django は Entry.DoesNotExist 例外を起こします。
同様に get() のクエリーが2つ以上のアイテムにマッチした場合にも、Djangoは文句を言います。この場合には、やはり同じクエリのモデルクラスの属性の MultipleObjectsReturned 例外が起こります。
QuerySet メソッドLink to this heading#データベースからオブジェクトを検索する必要がある大抵の場合は、 all(), get(), filter() および exclude() のいずれかを使うことになるでしょう。しかしこれらのメソッドだけでは不十分な場合は、さまざまな QuerySet メソッドの全リストが掲載されている QuerySet API Reference を参照してください。
QuerySet の要素数を制限するLink to this heading#Python のリストスライスのサブセットを使うことで QuerySet の結果を特定の要素数に制限することができます。これは SQL の LIMIT と OFFSET 句に対応します。
たとえば、次のコードは最初の5つのオブジェクトを返します (LIMIT 5)。
>>> Entry.objects.all()[:5]\n次のコードは、6番目から10番目までのオブジェクトを返します (OFFSET 5 LIMIT 5)。
>>> Entry.objects.all()[5:10]\n負のインデックスには対応していません (例: Entry.objects.all()[-1])。
一般に、 QuerySet をスライスしたとしても、新しい QuerySet が返り、クエリーの評価は行われません。例外は、Python のリストスライス構文の "step" パラメーターを使用した場合です。たとえば、次のコードは実際にクエリを実行し、最初の10個のオブジェクトから一つおきにとったオブジェクトのリストを返します。
>>> Entry.objects.all()[:10:2]\nリスト (例: SELECT foo FROM bar LIMIT 1) ではなく 1つの オブジェクトを取得するには、スライスではなく単純にリストのインデックスを使用してください。たとえば、次のコードは、ヘッドラインでアルファベット順にソートしたあと、データベースの1番目の Entry を返します。
>>> Entry.objects.order_by('headline')[0]\n上の例は次のコードとほとんど同じです。
\n>>> Entry.objects.order_by('headline')[0:1].get()\nただし、与えられた条件を満たすオブジェクトが存在しない場合に、前者は IndexError を起こすのに対して、後者は DoesNotExist を起こすことに注意してください。詳細については get() を参照してください。
フィールドルックアップは、SQL の WHERE 句の内容を指定する手段です。 QuerySet メソッド、 filter() 、 exclude() および get() にキーワード引数として指定します。
基本のルックアップキーワード引数は field__lookuptype=value という形を取ります (2文字連続するアンダースコアです)。たとえば、
>>> Entry.objects.filter(pub_date__lte='2006-01-01')\nというコードは、(だいたい) 次の SQL 文に変換されます。
\nSELECT * FROM blog_entry WHERE pub_date <= '2006-01-01';\nルックアップに指定するフィールドはモデルが持つフィールド名でなければなりません。ただし1つだけ例外があり、 ForeignKey の場合にはフィールド名の末尾に _id を付けた名前を指定することができます。その場合、value パラメータには外部モデルのプライマリーキーの生の値を書くことが期待されます。
>>> Entry.objects.filter(blog_id=4)\n向こうなキーワード引数を指定すると、ルックアップ関数は TypeError を起こします。
データベース API は約30個のルックアップタイプをサポートしており、完全なガイドは field lookup reference で見ることができます。ルックアップを使って何ができるのかがよく分かるように、以下によく使う一般的なルックアップをいくつか挙げます。
\nexact完全な ("exact") マッチを行います。たとえば、
\n>>> Entry.objects.get(headline__exact="Cat bites dog")\nは次のような SQL を生成します。
\nSELECT ... WHERE headline = 'Cat bites dog';\nルックアップタイプを指定しなかった場合、つまりキーワード引数がダブルアンダースコアを含まない場合、ルックアップタイプは exact が指定されたものとみなされます。
たとえば、次の2つの文は等価です。
\n>>> Blog.objects.get(id__exact=14) # Explicit form\n>>> Blog.objects.get(id=14) # __exact is implied\nexact ルックアップが最もよく使われるため、利便性のためにこのようになっています。
iexactcase-insensitive なマッチを行います。したがって、次のクエリ
\n>>> Blog.objects.get(name__iexact="beatles blog")\nは "Beatles Blog" 、 "beatles blog" 、あるいは "BeAtlES blOG" というタイトルを持つ Blog にもマッチします。
containscase-sensitive な部分一致テストを行います。たとえば、
\nEntry.objects.get(headline__contains='Lennon')\nはだいたい次のような SQL に変換されます。
\nSELECT ... WHERE headline LIKE '%Lennon%';\nこの例では、ヘッドライン 'Today Lennon honored' にはマッチしても 'today lennon honored' にはマッチしないことに注意してください。
case-insensitive バージョンの icontains もあります。
startswith と endswithそれぞれ starts-with と ends-with 検索を行います。case-insensitive バージョン istartswith と iendswith もあります。
繰り返しになりますが、以上はルックアップの表面をさらったに過ぎません。完全なリファレンスは field lookup reference を参照してください。
\nDjango はルックアップの中でリレーションを「横断する」強力で直感的な方法を提供します。あなたのために、背後で SQL の JOIN を自動的に実行しています。リレーションを横断するには、使いたいフィールドにたどり着くまで、モデル間を横断する関連フィールドのフィールド名をダブルアンダースコアで繋ぐだけでいいです。
次の例は、name に 'Beatles Blog' を持つ Blog のすべての Entry オブジェクトを取得します。
>>> Entry.objects.filter(blog__name='Beatles Blog')\nこの横断は好きなだけ深くすることができます。
\nIt works backwards, too. To refer to a "reverse" relationship, just use the\nlowercase name of the model.
\n次の例は、 少なくとも1つの headline が 'Lennon' を含む Entry を持つ、すべての Blog オブジェクトを取得します。
>>> Blog.objects.filter(entry__headline__contains='Lennon')\nIf you are filtering across multiple relationships and one of the intermediate\nmodels doesn't have a value that meets the filter condition, Django will treat\nit as if there is an empty (all values are NULL), but valid, object there.\nAll this means is that no error will be raised. For example, in this filter:
Blog.objects.filter(entry__authors__name='Lennon')\n(if there was a related Author model), if there was no author\nassociated with an entry, it would be treated as if there was also no name\nattached, rather than raising an error because of the missing author.\nUsually this is exactly what you want to have happen. The only case where it\nmight be confusing is if you are using isnull. Thus:
Blog.objects.filter(entry__authors__name__isnull=True)\nwill return Blog objects that have an empty name on the author and\nalso those which have an empty author on the entry. If you don't want\nthose latter objects, you could write:
Blog.objects.filter(entry__authors__isnull=False, entry__authors__name__isnull=True)\nWhen you are filtering an object based on a\nManyToManyField or a reverse\nForeignKey, there are two different sorts of filter\nyou may be interested in. Consider the Blog/Entry relationship\n(Blog to Entry is a one-to-many relation). We might be interested in\nfinding blogs that have an entry which has both "Lennon" in the headline and\nwas published in 2008. Or we might want to find blogs that have an entry with\n"Lennon" in the headline as well as an entry that was published\nin 2008. Since there are multiple entries associated with a single Blog,\nboth of these queries are possible and make sense in some situations.
The same type of situation arises with a\nManyToManyField. For example, if an Entry has a\nManyToManyField called tags, we might want to\nfind entries linked to tags called "music" and "bands" or we might want an\nentry that contains a tag with a name of "music" and a status of "public".
To handle both of these situations, Django has a consistent way of processing\nfilter() calls. Everything inside a\nsingle filter() call is applied\nsimultaneously to filter out items matching all those requirements. Successive\nfilter() calls further restrict the set\nof objects, but for multi-valued relations, they apply to any object linked to\nthe primary model, not necessarily those objects that were selected by an\nearlier filter() call.
That may sound a bit confusing, so hopefully an example will clarify. To\nselect all blogs that contain entries with both "Lennon" in the headline\nand that were published in 2008 (the same entry satisfying both conditions),\nwe would write:
\nBlog.objects.filter(entry__headline__contains='Lennon', entry__pub_date__year=2008)\nTo select all blogs that contain an entry with "Lennon" in the headline\nas well as an entry that was published in 2008, we would write:
\nBlog.objects.filter(entry__headline__contains='Lennon').filter(entry__pub_date__year=2008)\nSuppose there is only one blog that had both entries containing "Lennon" and\nentries from 2008, but that none of the entries from 2008 contained "Lennon".\nThe first query would not return any blogs, but the second query would return\nthat one blog.
\nIn the second example, the first filter restricts the queryset to all those\nblogs linked to entries with "Lennon" in the headline. The second filter\nrestricts the set of blogs further to those that are also linked to entries\nthat were published in 2008. The entries selected by the second filter may or\nmay not be the same as the entries in the first filter. We are filtering the\nBlog items with each filter statement, not the Entry items.
これまでに与えられた例では、モデルのフィールドの値を定数と比較するフィルタを作ってきた。しかし、もしモデルのフィールドの値を同じモデルの他のフィールドの値を比較したい時にはどうすればいいのでしょう？
\nそのような比較を行うために、Django は F 式 を用意しています。 F() のインスタンスは、クエリの中でモデルのフィールドへの参照として振る舞います。したがって、この参照をクエリの中で使うことで、同じモデルのインスタンスの異なる2つのフィールドの値を比較することができます。
たとえば、pingback の数よりコメントの数が多いすべてのブログエントリーのリストを検索するには、pingback の数を参照する F() オブジェクトを作り、その F() オブジェクトをクエリの中で次のように使います。
>>> from django.db.models import F\n>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks'))\nDjango supports the use of addition, subtraction, multiplication,\ndivision, modulo, and power arithmetic with F() objects, both with constants\nand with other F() objects. To find all the blog entries with more than\ntwice as many comments as pingbacks, we modify the query:
>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)\nTo find all the entries where the rating of the entry is less than the\nsum of the pingback count and comment count, we would issue the\nquery:
\n>>> Entry.objects.filter(rating__lt=F('n_comments') + F('n_pingbacks'))\nYou can also use the double underscore notation to span relationships in\nan F() object. An F() object with a double underscore will introduce\nany joins needed to access the related object. For example, to retrieve all\nthe entries where the author's name is the same as the blog name, we could\nissue the query:
>>> Entry.objects.filter(authors__name=F('blog__name'))\nFor date and date/time fields, you can add or subtract a\ntimedelta object. The following would return all entries\nthat were modified more than 3 days after they were published:
>>> from datetime import timedelta\n>>> Entry.objects.filter(mod_date__gt=F('pub_date') + timedelta(days=3))\nThe F() objects support bitwise operations by .bitand(), .bitor(),\n.bitrightshift(), and .bitleftshift(). For example:
>>> F('somefield').bitand(16)\npk ルックアップショートカットLink to this heading#利便性のために、Django は pk ルックアップショートカットを用意しています。pk とは "primary key" を表します。
プライマリーキーが id フィールドである Blog モデルの例では、次の3つの文はすべて等価です。
>>> Blog.objects.get(id__exact=14) # Explicit form\n>>> Blog.objects.get(id=14) # __exact is implied\n>>> Blog.objects.get(pk=14) # pk implies id__exact\nThe use of pk isn't limited to __exact queries -- any query term\ncan be combined with pk to perform a query on the primary key of a model:
# Get blogs entries with id 1, 4 and 7\n>>> Blog.objects.filter(pk__in=[1,4,7])\n\n# Get all blog entries with id > 14\n>>> Blog.objects.filter(pk__gt=14)\npk lookups also work across joins. For example, these three statements are\nequivalent:
>>> Entry.objects.filter(blog__id__exact=3) # Explicit form\n>>> Entry.objects.filter(blog__id=3) # __exact is implied\n>>> Entry.objects.filter(blog__pk=3) # __pk implies __id__exact\nLIKE 文の中ではパーセント記号とアンダースコアがエスケープされるLink to this heading#The field lookups that equate to LIKE SQL statements (iexact,\ncontains, icontains, startswith, istartswith, endswith\nand iendswith) will automatically escape the two special characters used in\nLIKE statements -- the percent sign and the underscore. (In a LIKE\nstatement, the percent sign signifies a multiple-character wildcard and the\nunderscore signifies a single-character wildcard.)
This means things should work intuitively, so the abstraction doesn't leak.\nFor example, to retrieve all the entries that contain a percent sign, just use\nthe percent sign as any other character:
\n>>> Entry.objects.filter(headline__contains='%')\nDjango takes care of the quoting for you; the resulting SQL will look something\nlike this:
\nSELECT ... WHERE headline LIKE '%\\%%';\nSame goes for underscores. Both percentage signs and underscores are handled\nfor you transparently.
\nQuerySetLink to this heading#それぞれの QuerySet には、データベースへのアクセスを最小にするために内部にキャッシュがあります。キャッシュのしくみを理解すれば、最も効率の良いコードが書けるようになります。
In a newly created QuerySet, the cache is\nempty. The first time a QuerySet is evaluated\n-- and, hence, a database query happens -- Django saves the query results in\nthe QuerySet’s cache and returns the results\nthat have been explicitly requested (e.g., the next element, if the\nQuerySet is being iterated over). Subsequent\nevaluations of the QuerySet reuse the cached\nresults.
Keep this caching behavior in mind, because it may bite you if you don't use\nyour QuerySets correctly. For example, the\nfollowing will create two QuerySets, evaluate\nthem, and throw them away:
>>> print([e.headline for e in Entry.objects.all()])\n>>> print([e.pub_date for e in Entry.objects.all()])\nThat means the same database query will be executed twice, effectively doubling\nyour database load. Also, there's a possibility the two lists may not include\nthe same database records, because an Entry may have been added or deleted\nin the split second between the two requests.
To avoid this problem, simply save the\nQuerySet and reuse it:
>>> queryset = Entry.objects.all()\n>>> print([p.headline for p in queryset]) # Evaluate the query set.\n>>> print([p.pub_date for p in queryset]) # Re-use the cache from the evaluation.\nQuerySet がキャッシュされない場合Link to this heading#Querysets do not always cache their results. When evaluating only part of\nthe queryset, the cache is checked, but if it is not populated then the items\nreturned by the subsequent query are not cached. Specifically, this means that\nlimiting the queryset using an array slice or an\nindex will not populate the cache.
\nFor example, repeatedly getting a certain index in a queryset object will query\nthe database each time:
\n>>> queryset = Entry.objects.all()\n>>> print(queryset[5]) # Queries the database\n>>> print(queryset[5]) # Queries the database again\nHowever, if the entire queryset has already been evaluated, the cache will be\nchecked instead:
\n>>> queryset = Entry.objects.all()\n>>> [entry for entry in queryset] # Queries the database\n>>> print(queryset[5]) # Uses cache\n>>> print(queryset[5]) # Uses cache\nHere are some examples of other actions that will result in the entire queryset\nbeing evaluated and therefore populate the cache:
\n>>> [entry for entry in queryset]\n>>> bool(queryset)\n>>> entry in queryset\n>>> list(queryset)\nQ オブジェクトを用いた複雑な検索Link to this heading#Keyword argument queries -- in filter(),\netc. -- are "AND"ed together. If you need to execute more complex queries (for\nexample, queries with OR statements), you can use Q objects.
A Q object (django.db.models.Q) is an object\nused to encapsulate a collection of keyword arguments. These keyword arguments\nare specified as in "Field lookups" above.
たとえば、次の Q オブジェクトは、1つの LIKE クエリをカプセル化しています。
from django.db.models import Q\nQ(question__startswith='What')\nQ オブジェクトは & や | 演算子を使って結合することができます。2つの Q オブジェクトに演算子が作用すると、1つの新しい Q オブジェクトが生まれます。
たとえば、次の文は2つの "question__startswith" の "OR" を表す、1つの Q オブジェクトを生み出します。
Q(question__startswith='Who') | Q(question__startswith='What')\nこのコードは次の SQL の WHERE 句と同等です。
WHERE question LIKE 'Who%' OR question LIKE 'What%'\nYou can compose statements of arbitrary complexity by combining Q objects\nwith the & and | operators and use parenthetical grouping. Also, Q\nobjects can be negated using the ~ operator, allowing for combined lookups\nthat combine both a normal query and a negated (NOT) query:
Q(question__startswith='Who') | ~Q(pub_date__year=2005)\nEach lookup function that takes keyword-arguments\n(e.g. filter(),\nexclude(),\nget()) can also be passed one or more\nQ objects as positional (not-named) arguments. If you provide multiple\nQ object arguments to a lookup function, the arguments will be "AND"ed\ntogether. For example:
Poll.objects.get(\n Q(question__startswith='Who'),\n Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6))\n)\n... roughly translates into the SQL:
\nSELECT * from polls WHERE question LIKE 'Who%'\n AND (pub_date = '2005-05-02' OR pub_date = '2005-05-06')\nLookup functions can mix the use of Q objects and keyword arguments. All\narguments provided to a lookup function (be they keyword arguments or Q\nobjects) are "AND"ed together. However, if a Q object is provided, it must\nprecede the definition of any keyword arguments. For example:
Poll.objects.get(\n Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6)),\n question__startswith='Who',\n)\n... would be a valid query, equivalent to the previous example; but:
\n# INVALID QUERY\nPoll.objects.get(\n question__startswith='Who',\n Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6))\n)\n... would not be valid.
\n\nTo compare two model instances, just use the standard Python comparison operator,\nthe double equals sign: ==. Behind the scenes, that compares the primary\nkey values of two models.
Using the Entry example above, the following two statements are equivalent:
>>> some_entry == other_entry\n>>> some_entry.id == other_entry.id\nIf a model's primary key isn't called id, no problem. Comparisons will\nalways use the primary key, whatever it's called. For example, if a model's\nprimary key field is called name, these two statements are equivalent:
>>> some_obj == other_obj\n>>> some_obj.name == other_obj.name\nThe delete method, conveniently, is named\ndelete(). This method immediately deletes the\nobject and returns the number of objects deleted and a dictionary with\nthe number of deletions per object type. Example:
>>> e.delete()\n(1, {'weblog.Entry': 1})\nYou can also delete objects in bulk. Every\nQuerySet has a\ndelete() method, which deletes all\nmembers of that QuerySet.
For example, this deletes all Entry objects with a pub_date year of\n2005:
>>> Entry.objects.filter(pub_date__year=2005).delete()\n(5, {'webapp.Entry': 5})\nKeep in mind that this will, whenever possible, be executed purely in SQL, and\nso the delete() methods of individual object instances will not necessarily\nbe called during the process. If you've provided a custom delete() method\non a model class and want to ensure that it is called, you will need to\n"manually" delete instances of that model (e.g., by iterating over a\nQuerySet and calling delete() on each\nobject individually) rather than using the bulk\ndelete() method of a\nQuerySet.
When Django deletes an object, by default it emulates the behavior of the SQL\nconstraint ON DELETE CASCADE -- in other words, any objects which had\nforeign keys pointing at the object to be deleted will be deleted along with\nit. For example:
b = Blog.objects.get(pk=1)\n# This will delete the Blog and all of its Entry objects.\nb.delete()\nThis cascade behavior is customizable via the\non_delete argument to the\nForeignKey.
Note that delete() is the only\nQuerySet method that is not exposed on a\nManager itself. This is a safety mechanism to\nprevent you from accidentally requesting Entry.objects.delete(), and\ndeleting all the entries. If you do want to delete all the objects, then\nyou have to explicitly request a complete query set:
Entry.objects.all().delete()\nAlthough there is no built-in method for copying model instances, it is\npossible to easily create new instance with all fields' values copied. In the\nsimplest case, you can just set pk to None. Using our blog example:
blog = Blog(name='My blog', tagline='Blogging is easy')\nblog.save() # blog.pk == 1\n\nblog.pk = None\nblog.save() # blog.pk == 2\nThings get more complicated if you use inheritance. Consider a subclass of\nBlog:
class ThemeBlog(Blog):\n theme = models.CharField(max_length=200)\n\ndjango_blog = ThemeBlog(name='Django', tagline='Django is easy', theme='python')\ndjango_blog.save() # django_blog.pk == 3\nDue to how inheritance works, you have to set both pk and id to None:
django_blog.pk = None\ndjango_blog.id = None\ndjango_blog.save() # django_blog.pk == 4\nThis process doesn't copy relations that aren't part of the model's database\ntable. For example, Entry has a ManyToManyField to Author. After\nduplicating an entry, you must set the many-to-many relations for the new\nentry:
entry = Entry.objects.all()[0] # some previous entry\nold_authors = entry.authors.all()\nentry.pk = None\nentry.save()\nentry.authors.set(old_authors)\nFor a OneToOneField, you must duplicate the related object and assign it\nto the new object's field to avoid violating the one-to-one unique constraint.\nFor example, assuming entry is already duplicated as above:
detail = EntryDetail.objects.all()[0]\ndetail.pk = None\ndetail.entry = entry\ndetail.save()\nSometimes you want to set a field to a particular value for all the objects in\na QuerySet. You can do this with the\nupdate() method. For example:
# Update all the headlines with pub_date in 2007.\nEntry.objects.filter(pub_date__year=2007).update(headline='Everything is the same')\nYou can only set non-relation fields and ForeignKey\nfields using this method. To update a non-relation field, provide the new value\nas a constant. To update ForeignKey fields, set the\nnew value to be the new model instance you want to point to. For example:
>>> b = Blog.objects.get(pk=1)\n\n# Change every Entry so that it belongs to this Blog.\n>>> Entry.objects.all().update(blog=b)\nThe update() method is applied instantly and returns the number of rows\nmatched by the query (which may not be equal to the number of rows updated if\nsome rows already have the new value). The only restriction on the\nQuerySet being updated is that it can only\naccess one database table: the model's main table. You can filter based on\nrelated fields, but you can only update columns in the model's main\ntable. Example:
>>> b = Blog.objects.get(pk=1)\n\n# Update all the headlines belonging to this Blog.\n>>> Entry.objects.select_related().filter(blog=b).update(headline='Everything is the same')\nBe aware that the update() method is converted directly to an SQL\nstatement. It is a bulk operation for direct updates. It doesn't run any\nsave() methods on your models, or emit the\npre_save or post_save signals (which are a consequence of calling\nsave()), or honor the\nauto_now field option.\nIf you want to save every item in a QuerySet\nand make sure that the save() method is called on\neach instance, you don't need any special function to handle that. Just loop\nover them and call save():
for item in my_queryset:\n item.save()\nCalls to update can also use F expressions to\nupdate one field based on the value of another field in the model. This is\nespecially useful for incrementing counters based upon their current value. For\nexample, to increment the pingback count for every entry in the blog:
>>> Entry.objects.all().update(n_pingbacks=F('n_pingbacks') + 1)\nHowever, unlike F() objects in filter and exclude clauses, you can't\nintroduce joins when you use F() objects in an update -- you can only\nreference fields local to the model being updated. If you attempt to introduce\na join with an F() object, a FieldError will be raised:
# This will raise a FieldError\n>>> Entry.objects.update(headline=F('blog__name'))\nIf you find yourself needing to write an SQL query that is too complex for\nDjango's database-mapper to handle, you can fall back on writing SQL by hand.\nDjango has a couple of options for writing raw SQL queries; see\n素の SQL 文の実行.
\nFinally, it's important to note that the Django database layer is merely an\ninterface to your database. You can access your database via other tools,\nprogramming languages or database frameworks; there's nothing Django-specific\nabout your database.
\n