このドキュメントでは、Model API の詳細を説明しています。モデル と データベースクエリ ガイドにある説明を前提としていますので、このドキュメントを読む前にこの 2 つを読んでおいた方がよいでしょう。
このドキュメント全体を通して、データベースクエリガイド で使った Weblog モデル例 を使用します。
\nモデルの新しいインスタンスを作成するには、他の Python クラスと同様に単にインスタンス化してください:
\nキーワード引数は、シンプルに、モデル内で定義したフィールドの名前です。モデルをインスタンス化しても、データベースには何もしないことに注意してください。データベースとやり取りするには save() を使う必要があります。
from_db() メソッドを使うと、データベースから読み込むときのモデルインスタンス作成をカスタマイズすることができます。
The db argument contains the database alias for the database the model\nis loaded from, field_names contains the names of all loaded fields, and\nvalues contains the loaded values for each field in field_names. The\nfield_names are in the same order as the values. If all of the model's\nfields are present, then values are guaranteed to be in the order\n__init__() expects them. That is, the instance can be created by\ncls(*values). If any fields are deferred, they won't appear in\nfield_names. In that case, assign a value of django.db.models.DEFERRED\nto each of the missing fields.
In addition to creating the new model, the from_db() method must set the\nadding and db flags in the new instance's _state attribute.
Below is an example showing how to record the initial values of fields that\nare loaded from the database:
\nfrom django.db.models import DEFERRED\n\n@classmethod\ndef from_db(cls, db, field_names, values):\n # Default implementation of from_db() (subject to change and could\n # be replaced with super()).\n if len(values) != len(cls._meta.concrete_fields):\n values = list(values)\n values.reverse()\n values = [\n values.pop() if f.attname in field_names else DEFERRED\n for f in cls._meta.concrete_fields\n ]\n instance = cls(*values)\n instance._state.adding = False\n instance._state.db = db\n # customization to store the original field values on the instance\n instance._loaded_values = dict(zip(field_names, values))\n return instance\n\ndef save(self, *args, **kwargs):\n # Check how the current values differ from ._loaded_values. For example,\n # prevent changing the creator_id of the model. (This example doesn't\n # support cases where 'creator_id' is deferred).\n if not self._state.adding and (\n self.creator_id != self._loaded_values['creator_id']):\n raise ValueError("Updating the value of creator isn't allowed")\n super(...).save(*args, **kwargs)\nThe example above shows a full from_db() implementation to clarify how that\nis done. In this case it would of course be possible to just use super() call\nin the from_db() method.
If you delete a field from a model instance, accessing it again reloads the\nvalue from the database:
\n>>> obj = MyModel.objects.first()\n>>> del obj.field\n>>> obj.field # Loads the field from the database\nIf you need to reload a model's values from the database, you can use the\nrefresh_from_db() method. When this method is called without arguments the\nfollowing is done:
All non-deferred fields of the model are updated to the values currently\npresent in the database.
The previously loaded related instances for which the relation's value is no\nlonger valid are removed from the reloaded instance. For example, if you have\na foreign key from the reloaded instance to another model with name\nAuthor, then if obj.author_id != obj.author.id, obj.author will\nbe thrown away, and when next accessed it will be reloaded with the value of\nobj.author_id.
Only fields of the model are reloaded from the database. Other\ndatabase-dependent values such as annotations aren't reloaded. Any\n@cached_property attributes\naren't cleared either.
The reloading happens from the database the instance was loaded from, or from\nthe default database if the instance wasn't loaded from the database. The\nusing argument can be used to force the database used for reloading.
It is possible to force the set of fields to be loaded by using the fields\nargument.
For example, to test that an update() call resulted in the expected\nupdate, you could write a test similar to this:
def test_update_result(self):\n obj = MyModel.objects.create(val=1)\n MyModel.objects.filter(pk=obj.pk).update(val=F('val') + 1)\n # At this point obj.val is still 1, but the value in the database\n # was updated to 2. The object's updated value needs to be reloaded\n # from the database.\n obj.refresh_from_db()\n self.assertEqual(obj.val, 2)\nNote that when deferred fields are accessed, the loading of the deferred\nfield's value happens through this method. Thus it is possible to customize\nthe way deferred loading happens. The example below shows how one can reload\nall of the instance's fields when a deferred field is reloaded:
\nclass ExampleModel(models.Model):\n def refresh_from_db(self, using=None, fields=None, **kwargs):\n # fields contains the name of the deferred field to be\n # loaded.\n if fields is not None:\n fields = set(fields)\n deferred_fields = self.get_deferred_fields()\n # If any deferred field is going to be loaded\n if fields.intersection(deferred_fields):\n # then load all of them\n fields = fields.union(deferred_fields)\n super(ExampleModel, self).refresh_from_db(using, fields, **kwargs)\nA helper method that returns a set containing the attribute names of all those\nfields that are currently deferred for this model.
\nモデルのバリデーションには 3 つのステップがあります:
\nモデルフィールドを検証する - Model.clean_fields()
モデル全体を検証する - Model.clean()
フィールドの一意性を検証する - Model.validate_unique()
モデルの full_clean() メソッドを使うと、3 つ全てのステップが実行されます。
ModelForm を使っているとき、is_valid() の呼び出しは、フォーム上に含まれる全てのフィールドに対して、これらの検証ステップを実行します。詳しくは ModelForm ドキュメント を参照してください。検証エラーを自分でコントロールしたい場合、もしくは ModelForm から検証を必要とするフィールドを除外した場合は、モデルの full_clean() メソッドだけを呼び出す必要があります。
このメソッドは、Model.clean_fields()、Model.clean()、そして Model.validate_unique() (validate_unique が True の場合) をこの順序で呼び出し、3 つ全てのステージでのエラーを含む message_dict 属性を持つ ValidationError を投げます。
省略可能な exclude 引数は、検証とクリーニングから除外するフィールド名のリストに使います。ModelForm は、この引数をフォーム上に存在しないフィールドを検証対象から除外するために使います。これは、エラーが発生してもユーザーによって修正できないからです。
モデルの save() メソッドを呼んだときでも full_clean() は自動的に 呼ばれない ことに注意してください。手動で作ったモデルに対して 1 ステップでモデル検証をしたいときには、手動で呼び出す必要があります。例えば:
from django.core.exceptions import ValidationError\ntry:\n article.full_clean()\nexcept ValidationError as e:\n # Do something based on the errors contained in e.message_dict.\n # Display them to a user, or handle them programmatically.\n pass\nfull_clean() が行う最初のステップは、個々のフィールドをそれぞれクリーニングすることです。
This method will validate all fields on your model. The optional exclude\nargument lets you provide a list of field names to exclude from validation. It\nwill raise a ValidationError if any fields fail\nvalidation.
The second step full_clean() performs is to call Model.clean().\nThis method should be overridden to perform custom validation on your model.
This method should be used to provide custom model validation, and to modify\nattributes on your model if desired. For instance, you could use it to\nautomatically provide a value for a field, or to do validation that requires\naccess to more than a single field:
\nimport datetime\nfrom django.core.exceptions import ValidationError\nfrom django.db import models\nfrom django.utils.translation import ugettext_lazy as _\n\nclass Article(models.Model):\n ...\n def clean(self):\n # Don't allow draft entries to have a pub_date.\n if self.status == 'draft' and self.pub_date is not None:\n raise ValidationError(_('Draft entries may not have a publication date.'))\n # Set the pub_date for published items if it hasn't been set already.\n if self.status == 'published' and self.pub_date is None:\n self.pub_date = datetime.date.today()\nNote, however, that like Model.full_clean(), a model's clean()\nmethod is not invoked when you call your model's save() method.
In the above example, the ValidationError\nexception raised by Model.clean() was instantiated with a string, so it\nwill be stored in a special error dictionary key,\nNON_FIELD_ERRORS. This key is used for errors\nthat are tied to the entire model instead of to a specific field:
from django.core.exceptions import ValidationError, NON_FIELD_ERRORS\ntry:\n article.full_clean()\nexcept ValidationError as e:\n non_field_errors = e.message_dict[NON_FIELD_ERRORS]\nTo assign exceptions to a specific field, instantiate the\nValidationError with a dictionary, where the\nkeys are the field names. We could update the previous example to assign the\nerror to the pub_date field:
class Article(models.Model):\n ...\n def clean(self):\n # Don't allow draft entries to have a pub_date.\n if self.status == 'draft' and self.pub_date is not None:\n raise ValidationError({'pub_date': _('Draft entries may not have a publication date.')})\n ...\nIf you detect errors in multiple fields during Model.clean(), you can also\npass a dictionary mapping field names to errors:
raise ValidationError({\n 'title': ValidationError(_('Missing title.'), code='required'),\n 'pub_date': ValidationError(_('Invalid date.'), code='invalid'),\n})\nFinally, full_clean() will check any unique constraints on your model.
This method is similar to clean_fields(), but validates all\nuniqueness constraints on your model instead of individual field values. The\noptional exclude argument allows you to provide a list of field names to\nexclude from validation. It will raise a\nValidationError if any fields fail validation.
Note that if you provide an exclude argument to validate_unique(), any\nunique_together constraint involving one of\nthe fields you provided will not be checked.
データベースにオブジェクトを保存し直すには、save() を呼び出します:
保存の動作をカスタマイズしたい場合は、save() メソッドをオーバーライドできます。詳しくは Overriding predefined model methods を参照してください。
モデル保存のプロセスには、いくつかの細かな注意点もあります; 以下の各セクションを参照してください。
\nIf a model has an AutoField — an auto-incrementing\nprimary key — then that auto-incremented value will be calculated and saved as\nan attribute on your object the first time you call save():
>>> b2 = Blog(name='Cheddar Talk', tagline='Thoughts on cheese.')\n>>> b2.id # Returns None, because b doesn't have an ID yet.\n>>> b2.save()\n>>> b2.id # Returns the ID of your new object.\nThere's no way to tell what the value of an ID will be before you call\nsave(), because that value is calculated by your database, not by Django.
For convenience, each model has an AutoField named\nid by default unless you explicitly specify primary_key=True on a field\nin your model. See the documentation for AutoField\nfor more details.
pk プロパティLink to this heading#Regardless of whether you define a primary key field yourself, or let Django\nsupply one for you, each model will have a property called pk. It behaves\nlike a normal attribute on the model, but is actually an alias for whichever\nattribute is the primary key field for the model. You can read and set this\nvalue, just as you would for any other attribute, and it will update the\ncorrect field in the model.
If a model has an AutoField but you want to define a\nnew object's ID explicitly when saving, just define it explicitly before\nsaving, rather than relying on the auto-assignment of the ID:
>>> b3 = Blog(id=3, name='Cheddar Talk', tagline='Thoughts on cheese.')\n>>> b3.id # Returns 3.\n>>> b3.save()\n>>> b3.id # Returns 3.\nIf you assign auto-primary-key values manually, make sure not to use an\nalready-existing primary-key value! If you create a new object with an explicit\nprimary-key value that already exists in the database, Django will assume you're\nchanging the existing record rather than creating a new one.
\nGiven the above 'Cheddar Talk' blog example, this example would override the\nprevious record in the database:
b4 = Blog(id=3, name='Not Cheddar', tagline='Anything but cheese.')\nb4.save() # Overrides the previous blog with ID=3!\nSee How Django knows to UPDATE vs. INSERT, below, for the reason this\nhappens.
\nExplicitly specifying auto-primary-key values is mostly useful for bulk-saving\nobjects, when you're confident you won't have primary-key collision.
\nWhen you save an object, Django performs the following steps:
\nEmit a pre-save signal. The pre_save\nsignal is sent, allowing any functions listening for that signal to do\nsomething.
Preprocess the data. Each field's\npre_save() method is called to perform any\nautomated data modification that's needed. For example, the date/time fields\noverride pre_save() to implement\nauto_now_add and\nauto_now.
Prepare the data for the database. Each field's\nget_db_prep_save() method is asked to provide\nits current value in a data type that can be written to the database.
Most fields don't require data preparation. Simple data types, such as\nintegers and strings, are 'ready to write' as a Python object. However, more\ncomplex data types often require some modification.
\nFor example, DateField fields use a Python\ndatetime object to store data. Databases don't store datetime\nobjects, so the field value must be converted into an ISO-compliant date\nstring for insertion into the database.
Insert the data into the database. The preprocessed, prepared data is\ncomposed into an SQL statement for insertion into the database.
Emit a post-save signal. The post_save\nsignal is sent, allowing any functions listening for that signal to do\nsomething.
Django データベースオブジェクトが、オブジェクトの作成と変更に同じ save() メソッドを使うことにお気づきかもしれません。Django は INSERT や UPDATE といった SQL ステートメントを抽象化しています。特に、save() を呼び出すとき、Django は以下のアルゴリズムを実行します:
オブジェクトのプライマリキー属性が True と評価される値にセットされている場合 (例えば None や空の文字列以外の場合)。Django は UPDATE を実行します。
オブジェクトのプライマリキー属性がセット されていない、もしくは UPDATE が何もアップデートしなかった場合、Django は INSERT を実行します。
ここで重要なのは、そのプライマリキーが使われていないことが保証できない場合、新しいオブジェクトを保存するときに明示的にプライマリキーの値を指定しないように気をつけることです。このニュアンスについては、上述の 自動プライマリキーの値を明示的に指定する と下記の INSERT や UPDATE を強制する を参照してください。
\nIn Django 1.5 and earlier, Django did a SELECT when the primary key\nattribute was set. If the SELECT found a row, then Django did an UPDATE,\notherwise it did an INSERT. The old algorithm results in one more query in\nthe UPDATE case. There are some rare cases where the database doesn't\nreport that a row was updated even if the database contains a row for the\nobject's primary key value. An example is the PostgreSQL ON UPDATE trigger\nwhich returns NULL. In such cases it is possible to revert to the old\nalgorithm by setting the select_on_save\noption to True.
まれに、save() に対して SQL の INSERT を強制してフォールバックで UPDATE を実行しない (もしくは逆に: 可能ならば更新をして新しい行を追加しない) ように強制する必要があります。こうしたケースでは、force_insert=True や force_update=True パラメータを save() メソッドに渡すことができます。当然のことですが、両方のパラメータを渡すとエラーになります: 追加と更新を同時にはできません！
これらのパラメータを必要とするのは、まれであるべきです。Django は、ほとんどの場合で正しく処理を行い、オーバーライドしようとすると追跡が難しいエラーの原因となります。この機能は応用的な場合のみに使用してください。
\nupdate_fields を使うと force_update と同じように更新を強制します。
現在の値をインクリメントまたはデクリメントするなど、フィールドで単純な算術タスクを実行する必要が生じることがあります。 これを達成する明白な方法は、以下のようにすることです:
\n>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')\n>>> product.number_sold += 1\n>>> product.save()\nデータベースから取得した古い number_sold の値は 10 でした。そして、11 という値がデータベースに書き直されます。
このプロセスは、新しい値の明示的な割り当てではなく、元のフィールド値に対する更新を表現することによって、競合状態を回避しながら 堅牢にすることができます。 Djangoは、このような相対的な更新を行うための F expressions を提供しています。 F expressions を使用すると、上の例は以下のように表されます:
>>> from django.db.models import F\n>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')\n>>> product.number_sold = F('number_sold') + 1\n>>> product.save()\n詳しくは、F expressions とこれに対する 更新クエリ内で使う を参照してください。
save() にキーワード引数 update_fields 内でフィールドリストの名前が渡された場合、このリスト内で指定されたフィールドだけが更新されます。これは、オブジェクトの 1 つないし少数のフィールドだけを更新したい場合に望ましいでしょう。データベースで全てのモデルフィールドを更新しないようにすると、実行速度が少し向上します。例えば:
product.name = 'Name changed again'\nproduct.save(update_fields=['name'])\nupdate_fields 引数は文字列を含む任意のイテラブルです。空の update_fields イテラブルは保存をスキップします。None という値は全てのフィールドを更新します。
update_fields を指定すると更新を強制します。
遅延モデルローディング (only() や defer()) を通してフェッチされたモデルを保存するとき、DB からロードされたフィールドだけが更新されます。実際には、このケースでは自動的な update_fields が存在します。遅延フィールドの値を追加もしくは変更した場合、フィールドは更新されたフィールドに追加されます。
オブジェクトに対して SQL DELETE を発行します。これはデータベースでオブジェクトの削除のみを行います; Python のインスタンスはなお存在しまたフィールド内にデータを持ち続けます。このメソッドは削除されるオブジェクトの数とオブジェクトタイプごとの削除の数のディクショナリを返します。
より詳しく (まとめてオブジェクトを削除する方法を含む) については、オブジェクトを削除する を参照してください。
\n独自の削除動作がほしいときは、delete() メソッドをオーバーライドすることができます。詳しくは Overriding predefined model methods を参照してください。
Sometimes with multi-table inheritance you may\nwant to delete only a child model's data. Specifying keep_parents=True will\nkeep the parent model's data.
When you pickle a model, its current state is pickled. When you unpickle\nit, it'll contain the model instance at the moment it was pickled, rather than\nthe data that's currently in the database.
A few object methods have special purposes.
\n__str__()Link to this heading#The __str__() method is called whenever you call str() on an object.\nDjango uses str(obj) in a number of places. Most notably, to display an\nobject in the Django admin site and as the value inserted into a template when\nit displays an object. Thus, you should always return a nice, human-readable\nrepresentation of the model from the __str__() method.
For example:
\nfrom django.db import models\nfrom django.utils.encoding import python_2_unicode_compatible\n\n@python_2_unicode_compatible # only if you need to support Python 2\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n\n def __str__(self):\n return '%s %s' % (self.first_name, self.last_name)\nIf you'd like compatibility with Python 2, you can decorate your model class\nwith python_2_unicode_compatible() as shown above.
__eq__()Link to this heading#The equality method is defined such that instances with the same primary\nkey value and the same concrete class are considered equal, except that\ninstances with a primary key value of None aren't equal to anything except\nthemselves. For proxy models, concrete class is defined as the model's first\nnon-proxy parent; for all other models it's simply the model's class.
For example:
\nfrom django.db import models\n\nclass MyModel(models.Model):\n id = models.AutoField(primary_key=True)\n\nclass MyProxyModel(MyModel):\n class Meta:\n proxy = True\n\nclass MultitableInherited(MyModel):\n pass\n\n# Primary keys compared\nMyModel(id=1) == MyModel(id=1)\nMyModel(id=1) != MyModel(id=2)\n# Primay keys are None\nMyModel(id=None) != MyModel(id=None)\n# Same instance\ninstance = MyModel(id=None)\ninstance == instance\n# Proxy model\nMyModel(id=1) == MyProxyModel(id=1)\n# Multi-table inheritance\nMyModel(id=1) != MultitableInherited(id=1)\n__hash__()Link to this heading#The __hash__() method is based on the instance's primary key value. It\nis effectively hash(obj.pk). If the instance doesn't have a primary key\nvalue then a TypeError will be raised (otherwise the __hash__()\nmethod would return different values before and after the instance is\nsaved, but changing the __hash__() value of an instance is\nforbidden in Python.
get_absolute_url()Link to this heading#Define a get_absolute_url() method to tell Django how to calculate the\ncanonical URL for an object. To callers, this method should appear to return a\nstring that can be used to refer to the object over HTTP.
For example:
\ndef get_absolute_url(self):\n return "/people/%i/" % self.id\nWhile this code is correct and simple, it may not be the most portable way to\nto write this kind of method. The reverse() function is\nusually the best approach.
For example:
\ndef get_absolute_url(self):\n from django.urls import reverse\n return reverse('people.views.details', args=[str(self.id)])\nOne place Django uses get_absolute_url() is in the admin app. If an object\ndefines this method, the object-editing page will have a "View on site" link\nthat will jump you directly to the object's public view, as given by\nget_absolute_url().
Similarly, a couple of other bits of Django, such as the syndication feed\nframework, use get_absolute_url() when it is\ndefined. If it makes sense for your model's instances to each have a unique\nURL, you should define get_absolute_url().
It's good practice to use get_absolute_url() in templates, instead of\nhard-coding your objects' URLs. For example, this template code is bad:
<!-- BAD template code. Avoid! -->\n<a href="/people/{{ object.id }}/">{{ object.name }}</a>\nThis template code is much better:
\n<a href="{{ object.get_absolute_url }}">{{ object.name }}</a>\nThe logic here is that if you change the URL structure of your objects, even\nfor something simple such as correcting a spelling error, you don't want to\nhave to track down every place that the URL might be created. Specify it once,\nin get_absolute_url() and have all your other code call that one place.
In addition to save(), delete(), a model object\nmight have some of the following methods:
For every field that has choices set, the\nobject will have a get_FOO_display() method, where FOO is the name of\nthe field. This method returns the "human-readable" value of the field.
For example:
\nfrom django.db import models\n\nclass Person(models.Model):\n SHIRT_SIZES = (\n ('S', 'Small'),\n ('M', 'Medium'),\n ('L', 'Large'),\n )\n name = models.CharField(max_length=60)\n shirt_size = models.CharField(max_length=2, choices=SHIRT_SIZES)\n>>> p = Person(name="Fred Flintstone", shirt_size="L")\n>>> p.save()\n>>> p.shirt_size\n'L'\n>>> p.get_shirt_size_display()\n'Large'\nFor every DateField and\nDateTimeField that does not have null=True, the object will have get_next_by_FOO() and\nget_previous_by_FOO() methods, where FOO is the name of the field. This\nreturns the next and previous object with respect to the date field, raising\na DoesNotExist exception when appropriate.
Both of these methods will perform their queries using the default\nmanager for the model. If you need to emulate filtering used by a\ncustom manager, or want to perform one-off custom filtering, both\nmethods also accept optional keyword arguments, which should be in the\nformat described in Field lookups.
\nNote that in the case of identical date values, these methods will use the\nprimary key as a tie-breaker. This guarantees that no records are skipped or\nduplicated. That also means you cannot use those methods on unsaved objects.
\nDoesNotExistLink to this heading#This exception is raised by the ORM in a couple places, for example by\nQuerySet.get() when an object\nis not found for the given query parameters.
Django provides a DoesNotExist exception as an attribute of each model\nclass to identify the class of object that could not be found and to allow\nyou to catch a particular model class with try/except. The exception is\na subclass of django.core.exceptions.ObjectDoesNotExist.