モデルインスタンスリファレンス¶
このドキュメントでは、Model
API の詳細を説明しています。モデル と データベースクエリ ガイドにある説明を前提としていますので、このドキュメントを読む前にこの 2 つを読んでおいた方がよいでしょう。
このドキュメント全体を通して、データベースクエリガイド で使った Weblog モデル例 を使用します。
オブジェクトを作成する¶
モデルの新しいインスタンスを作成するには、他の Python クラスと同様に単にインスタンス化してください:
キーワード引数は、シンプルに、モデル内で定義したフィールドの名前です。モデルをインスタンス化しても、データベースには何もしないことに注意してください。データベースとやり取りするには save()
を使う必要があります。
注釈
__init__
メソッドをオーバーライドしてモデルをカスタマイズする誘惑に駆られるかもしれません。その場合は、とは言え、あらゆる変更がモデルインスタンスを保存しないように、呼び出しシグネチャを変更しないように配慮してください。__init__
をオーバーライドするのではなく、以下のいずれかのアプローチを試してみてください:
モデルクラスにクラスメソッドを追加する:
from django.db import models class Book(models.Model): title = models.CharField(max_length=100) @classmethod def create(cls, title): book = cls(title=title) # do something with the book return book book = Book.create("Pride and Prejudice")
独自のマネジャーにメソッドを追加する (通常推奨される方法です):
class BookManager(models.Manager): def create_book(self, title): book = self.create(title=title) # do something with the book return book class Book(models.Model): title = models.CharField(max_length=100) objects = BookManager() book = Book.objects.create_book("Pride and Prejudice")
モデルの読み込みをカスタマイズする¶
from_db()
メソッドを使うと、データベースから読み込むときのモデルインスタンス作成をカスタマイズすることができます。
引数 db
はモデルを読み込む対象となるデータベースへのエイリアスになります、 field_names
は読み込まれるすべてのフィールドの名前を持ち、そして values
は field_names
内各フィールドに対応した値を持ちます。 field_names
は values
と同じ並び順になります。モデルのフィールドが全て存在する場合、 values
はその順番が __init__()
が期待する順番である事が保障されます。つまり、そのインスタンスは cls(*values)
によって生成されえます。いずれかのフィールドが遅延評価されている場合、そのフィールドは field_names
内に出現しません。その場合、存在しない各フィールドには django.db.models.DEFERRED
の値が設定されています。
新たなモデルを作る事に加え、 from_db()
メソッドでは新たなインスタンスの属性 _state
内に adding
および db
フラグを設定しなければなりません。
以下はデータベースから読みだされたフィールドの初期値をどのように保存しているのかについてを示した例です:
from django.db.models import DEFERRED
@classmethod
def from_db(cls, db, field_names, values):
# Default implementation of from_db() (subject to change and could
# be replaced with super()).
if len(values) != len(cls._meta.concrete_fields):
values = list(values)
values.reverse()
values = [
values.pop() if f.attname in field_names else DEFERRED
for f in cls._meta.concrete_fields
]
instance = cls(*values)
instance._state.adding = False
instance._state.db = db
# customization to store the original field values on the instance
instance._loaded_values = dict(zip(field_names, values))
return instance
def save(self, *args, **kwargs):
# Check how the current values differ from ._loaded_values. For example,
# prevent changing the creator_id of the model. (This example doesn't
# support cases where 'creator_id' is deferred).
if not self._state.adding and (
self.creator_id != self._loaded_values['creator_id']):
raise ValueError("Updating the value of creator isn't allowed")
super(...).save(*args, **kwargs)
上の例ではその機能を明らかにするため from_db()
の実装を全て行いました。この実装を行う場合では当然 from_db()
メソッドから super()
を呼び出すだけでもかまいません。
以前のバージョンでは、 cls._deferred
を参照することで全てのフィールドが読みだされているか確認できました。この属性は削除されて django.db.models.DEFERRED
が新たに設定されました。
データベースからオブジェクトを再読み込みする¶
モデルのインスタンスからあるフィールドを削除した場合、再度アクセスする事でその値をデータベースから再読み込みします:
>>> obj = MyModel.objects.first()
>>> del obj.field
>>> obj.field # Loads the field from the database
以前のバージョンでは、削除されたフィールドにアクセスすると再読み込みをせずに AttributeError
を送出していました。
データベースからモデルの値を再読み込みする必要が有る場合は、 refresh_from_db()
メソッドを利用できます。引数なしでこのメソッドを呼び出した場合は以下の処理が行われます:
- モデル上の遅延評価されない全てのフィールドはその時点でデータベース上に存在する値に更新されます。
- リレーション経由で前もって読み出されたインスタンスで、リレーションの値が有効でなくなった物は再読み込みされたインスタンスから削除されます。例えば、再読み込みしたインスタンスから
Author
という名前で他のモデルに対する外部キーが存在した場合、obj.author_id != obj.author.id
という条件をこのメソッド呼び出し時に満たせなければ、obj.author
は破棄され、次にアクセスした際にobj.author_id
の値を用いて再読み込みされます。
データベースからはフィールドのみが再読み込みされます。それ以外のアノテーションのようなデータベース依存の値は更新されません。いずれの @cached_property
属性等も同様にクリアされる事はありません。
再読み込みはインスタンスを読み込むデータベースから、もしくはインスタンスがデータベースから読み込まれない場合はデフォルトのデータベースから行われます。 using
引数は再読み込みを行うデータベースを強制的に設定する際に用いることができます。
読み込むフィールドのセットを強制的に設定するには fields
引数を用いる事ができます。
例えば、update()
の呼び出しによって期待する更新が行われたかをテストするため、以下のようなテストを書くことができます:
def test_update_result(self):
obj = MyModel.objects.create(val=1)
MyModel.objects.filter(pk=obj.pk).update(val=F('val') + 1)
# At this point obj.val is still 1, but the value in the database
# was updated to 2. The object's updated value needs to be reloaded
# from the database.
obj.refresh_from_db()
self.assertEqual(obj.val, 2)
遅延評価されているフィールドにアクセスした場合、その遅延評価されるフィールドの読み込みはこのメソッドを経由する事に注意してください。そのため遅延評価の読み込みがどのように行われるかを独自に設定する事が可能です。以下の例は遅延評価するフィールドが再読み込みされた時どのようにしてインスタンス上のフィールド全てを再読み込みできるかを示しています:
class ExampleModel(models.Model):
def refresh_from_db(self, using=None, fields=None, **kwargs):
# fields contains the name of the deferred field to be
# loaded.
if fields is not None:
fields = set(fields)
deferred_fields = self.get_deferred_fields()
# If any deferred field is going to be loaded
if fields.intersection(deferred_fields):
# then load all of them
fields = fields.union(deferred_fields)
super(ExampleModel, self).refresh_from_db(using, fields, **kwargs)
対象となるモデルにおいて現在評価を遅延している全てのフィールドの属性名を持った集合を返すヘルパーメソッドです。
オブジェクトを検証 (バリデーション) する¶
モデルのバリデーションには 3 つのステップがあります:
- モデルフィールドを検証する -
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
try:
article.full_clean()
except ValidationError as e:
# Do something based on the errors contained in e.message_dict.
# Display them to a user, or handle them programmatically.
pass
full_clean()
が行う最初のステップは、個々のフィールドをそれぞれクリーニングすることです。
このメソッドはモデル上の全てのフィールドを検証します。オプションの exclude
引数には検証の対象から除外したいフィールド名のリストを渡すことができます。いずれかのフィールドで検証に失敗した場合は ValidationError
が送出されます。
full_clean()
の第二段階では Model.clean()
を呼び出します。このメソッドはモデル独自のバリデーションにオーバーライドされます。
This method should be used to provide custom model validation, and to modify attributes on your model if desired. For instance, you could use it to automatically provide a value for a field, or to do validation that requires access to more than a single field:
import datetime
from django.core.exceptions import ValidationError
from django.db import models
from django.utils.translation import ugettext_lazy as _
class Article(models.Model):
...
def clean(self):
# Don't allow draft entries to have a pub_date.
if self.status == 'draft' and self.pub_date is not None:
raise ValidationError(_('Draft entries may not have a publication date.'))
# Set the pub_date for published items if it hasn't been set already.
if self.status == 'published' and self.pub_date is None:
self.pub_date = datetime.date.today()
Note, however, that like Model.full_clean()
, a model’s clean()
method is not invoked when you call your model’s save()
method.
In the above example, the ValidationError
exception raised by Model.clean()
was instantiated with a string, so it
will be stored in a special error dictionary key,
NON_FIELD_ERRORS
. This key is used for errors
that are tied to the entire model instead of to a specific field:
from django.core.exceptions import ValidationError, NON_FIELD_ERRORS
try:
article.full_clean()
except ValidationError as e:
non_field_errors = e.message_dict[NON_FIELD_ERRORS]
To assign exceptions to a specific field, instantiate the
ValidationError
with a dictionary, where the
keys are the field names. We could update the previous example to assign the
error to the pub_date
field:
class Article(models.Model):
...
def clean(self):
# Don't allow draft entries to have a pub_date.
if self.status == 'draft' and self.pub_date is not None:
raise ValidationError({'pub_date': _('Draft entries may not have a publication date.')})
...
If you detect errors in multiple fields during Model.clean()
, you can also
pass a dictionary mapping field names to errors:
raise ValidationError({
'title': ValidationError(_('Missing title.'), code='required'),
'pub_date': ValidationError(_('Invalid date.'), code='invalid'),
})
Finally, full_clean()
will check any unique constraints on your model.
How to raise field-specific validation errors if those fields don’t appear in a ModelForm
You can’t raise validation errors in Model.clean()
for fields that
don’t appear in a model form (a form may limit its fields using
Meta.fields
or Meta.exclude
). Doing so will raise a ValueError
because the validation error won’t be able to be associated with the
excluded field.
To work around this dilemma, instead override Model.clean_fields()
as it receives the list of fields
that are excluded from validation. For example:
class Article(models.Model):
...
def clean_fields(self, exclude=None):
super(Article, self).clean_fields(exclude=exclude)
if self.status == 'draft' and self.pub_date is not None:
if exclude and 'status' in exclude:
raise ValidationError(
_('Draft entries may not have a publication date.')
)
else:
raise ValidationError({
'status': _(
'Set status to draft if there is not a '
'publication date.'
),
})
This method is similar to clean_fields()
, but validates all
uniqueness constraints on your model instead of individual field values. The
optional exclude
argument allows you to provide a list of field names to
exclude from validation. It will raise a
ValidationError
if any fields fail validation.
Note that if you provide an exclude
argument to validate_unique()
, any
unique_together
constraint involving one of
the fields you provided will not be checked.
オブジェクトを保存する¶
データベースにオブジェクトを保存し直すには、save()
を呼び出します:
-
Model.
save
(force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS, update_fields=None)[ソース]¶
保存の動作をカスタマイズしたい場合は、save()
メソッドをオーバーライドできます。詳しくは Overriding predefined model methods を参照してください。
モデル保存のプロセスには、いくつかの細かな注意点もあります; 以下の各セクションを参照してください。
自動インクリメントのプライマリキー¶
If a model has an AutoField
— an auto-incrementing
primary key — then that auto-incremented value will be calculated and saved as
an attribute on your object the first time you call save()
:
>>> b2 = Blog(name='Cheddar Talk', tagline='Thoughts on cheese.')
>>> b2.id # Returns None, because b doesn't have an ID yet.
>>> b2.save()
>>> b2.id # Returns the ID of your new object.
There’s no way to tell what the value of an ID will be before you call
save()
, because that value is calculated by your database, not by Django.
For convenience, each model has an AutoField
named
id
by default unless you explicitly specify primary_key=True
on a field
in your model. See the documentation for AutoField
for more details.
pk
プロパティ¶
-
Model.
pk
¶
Regardless of whether you define a primary key field yourself, or let Django
supply one for you, each model will have a property called pk
. It behaves
like a normal attribute on the model, but is actually an alias for whichever
attribute is the primary key field for the model. You can read and set this
value, just as you would for any other attribute, and it will update the
correct field in the model.
Explicitly specifying auto-primary-key values¶
If a model has an AutoField
but you want to define a
new object’s ID explicitly when saving, just define it explicitly before
saving, rather than relying on the auto-assignment of the ID:
>>> b3 = Blog(id=3, name='Cheddar Talk', tagline='Thoughts on cheese.')
>>> b3.id # Returns 3.
>>> b3.save()
>>> b3.id # Returns 3.
If you assign auto-primary-key values manually, make sure not to use an already-existing primary-key value! If you create a new object with an explicit primary-key value that already exists in the database, Django will assume you’re changing the existing record rather than creating a new one.
Given the above 'Cheddar Talk'
blog example, this example would override the
previous record in the database:
b4 = Blog(id=3, name='Not Cheddar', tagline='Anything but cheese.')
b4.save() # Overrides the previous blog with ID=3!
See How Django knows to UPDATE vs. INSERT, below, for the reason this happens.
Explicitly specifying auto-primary-key values is mostly useful for bulk-saving objects, when you’re confident you won’t have primary-key collision.
If you’re using PostgreSQL, the sequence associated with the primary key might need to be updated; see Manually-specifying values of auto-incrementing primary keys.
What happens when you save?¶
When you save an object, Django performs the following steps:
Emit a pre-save signal. The
pre_save
signal is sent, allowing any functions listening for that signal to do something.Preprocess the data. Each field’s
pre_save()
method is called to perform any automated data modification that’s needed. For example, the date/time fields overridepre_save()
to implementauto_now_add
andauto_now
.Prepare the data for the database. Each field’s
get_db_prep_save()
method is asked to provide its 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 integers and strings, are 『ready to write』 as a Python object. However, more complex data types often require some modification.
For example,
DateField
fields use a Pythondatetime
object to store data. Databases don’t storedatetime
objects, so the field value must be converted into an ISO-compliant date string for insertion into the database.Insert the data into the database. The preprocessed, prepared data is composed into an SQL statement for insertion into the database.
Emit a post-save signal. The
post_save
signal is sent, allowing any functions listening for that signal to do something.
Django が UPDATE と INSERT を見分ける方法¶
Django データベースオブジェクトが、オブジェクトの作成と変更に同じ save()
メソッドを使うことにお気づきかもしれません。Django は INSERT
や UPDATE
といった SQL ステートメントを抽象化しています。特に、save()
を呼び出すとき、Django は以下のアルゴリズムを実行します:
- オブジェクトのプライマリキー属性が
True
と評価される値にセットされている場合 (例えばNone
や空の文字列以外の場合)。Django はUPDATE
を実行します。 - オブジェクトのプライマリキー属性がセット されていない、もしくは
UPDATE
が何もアップデートしなかった場合、Django はINSERT
を実行します。
ここで重要なのは、そのプライマリキーが使われていないことが保証できない場合、新しいオブジェクトを保存するときに明示的にプライマリキーの値を指定しないように気をつけることです。このニュアンスについては、上述の 自動プライマリキーの値を明示的に指定する と下記の INSERT や UPDATE を強制する を参照してください。
In Django 1.5 and earlier, Django did a SELECT
when the primary key
attribute was set. If the SELECT
found a row, then Django did an UPDATE
,
otherwise it did an INSERT
. The old algorithm results in one more query in
the UPDATE
case. There are some rare cases where the database doesn’t
report that a row was updated even if the database contains a row for the
object’s primary key value. An example is the PostgreSQL ON UPDATE
trigger
which returns NULL
. In such cases it is possible to revert to the old
algorithm by setting the select_on_save
option to True
.
INSERT や UPDATE を強制する¶
まれに、save()
に対して SQL の INSERT
を強制してフォールバックで UPDATE
を実行しない (もしくは逆に: 可能ならば更新をして新しい行を追加しない) ように強制する必要があります。こうしたケースでは、force_insert=True
や force_update=True
パラメータを save()
メソッドに渡すことができます。当然のことですが、両方のパラメータを渡すとエラーになります: 追加と更新を同時にはできません!
これらのパラメータを必要とするのは、まれであるべきです。Django は、ほとんどの場合で正しく処理を行い、オーバーライドしようとすると追跡が難しいエラーの原因となります。この機能は応用的な場合のみに使用してください。
update_fields
を使うと force_update
と同じように更新を強制します。
既存のフィールドに基づいて属性を更新する¶
現在の値をインクリメントまたはデクリメントするなど、フィールドで単純な算術タスクを実行する必要が生じることがあります。 これを達成する明白な方法は、以下のようにすることです:
>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')
>>> product.number_sold += 1
>>> product.save()
データベースから取得した古い number_sold
の値は 10 でした。そして、11 という値がデータベースに書き直されます。
このプロセスは、新しい値の明示的な割り当てではなく、元のフィールド値に対する更新を表現することによって、競合状態を回避しながら 堅牢にすることができます。 Djangoは、このような相対的な更新を行うための F expressions
を提供しています。 F expressions
を使用すると、上の例は以下のように表されます:
>>> from django.db.models import F
>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')
>>> product.number_sold = F('number_sold') + 1
>>> product.save()
詳しくは、F expressions
とこれに対する 更新クエリ内で使う を参照してください。
どのフィールドを保存するか指定する¶
save()
にキーワード引数 update_fields
内でフィールドリストの名前が渡された場合、このリスト内で指定されたフィールドだけが更新されます。これは、オブジェクトの 1 つないし少数のフィールドだけを更新したい場合に望ましいでしょう。データベースで全てのモデルフィールドを更新しないようにすると、実行速度が少し向上します。例えば:
product.name = 'Name changed again'
product.save(update_fields=['name'])
update_fields
引数は文字列を含む任意のイテラブルです。空の update_fields
イテラブルは保存をスキップします。None という値は全てのフィールドを更新します。
update_fields
を指定すると更新を強制します。
遅延モデルローディング (only()
や defer()
) を通してフェッチされたモデルを保存するとき、DB からロードされたフィールドだけが更新されます。実際には、このケースでは自動的な update_fields
が存在します。遅延フィールドの値を追加もしくは変更した場合、フィールドは更新されたフィールドに追加されます。
オブジェクトを削除する¶
オブジェクトに対して SQL DELETE
を発行します。これはデータベースでオブジェクトの削除のみを行います; Python のインスタンスはなお存在しまたフィールド内にデータを持ち続けます。このメソッドは削除されるオブジェクトの数とオブジェクトタイプごとの削除の数のディクショナリを返します。
より詳しく (まとめてオブジェクトを削除する方法を含む) については、オブジェクトを削除する を参照してください。
独自の削除動作がほしいときは、delete()
メソッドをオーバーライドすることができます。詳しくは Overriding predefined model methods を参照してください。
Sometimes with multi-table inheritance you may
want to delete only a child model’s data. Specifying keep_parents=True
will
keep the parent model’s data.
Pickling objects¶
When you pickle
a model, its current state is pickled. When you unpickle
it, it’ll contain the model instance at the moment it was pickled, rather than
the data that’s currently in the database.
Other model instance methods¶
A few object methods have special purposes.
__str__()
¶
The __str__()
method is called whenever you call str()
on an object.
Django uses str(obj)
in a number of places. Most notably, to display an
object in the Django admin site and as the value inserted into a template when
it displays an object. Thus, you should always return a nice, human-readable
representation of the model from the __str__()
method.
For example:
from django.db import models
from django.utils.encoding import python_2_unicode_compatible
@python_2_unicode_compatible # only if you need to support Python 2
class Person(models.Model):
first_name = models.CharField(max_length=50)
last_name = models.CharField(max_length=50)
def __str__(self):
return '%s %s' % (self.first_name, self.last_name)
If you’d like compatibility with Python 2, you can decorate your model class
with python_2_unicode_compatible()
as shown above.
__eq__()
¶
The equality method is defined such that instances with the same primary
key value and the same concrete class are considered equal, except that
instances with a primary key value of None
aren’t equal to anything except
themselves. For proxy models, concrete class is defined as the model’s first
non-proxy parent; for all other models it’s simply the model’s class.
For example:
from django.db import models
class MyModel(models.Model):
id = models.AutoField(primary_key=True)
class MyProxyModel(MyModel):
class Meta:
proxy = True
class MultitableInherited(MyModel):
pass
# Primary keys compared
MyModel(id=1) == MyModel(id=1)
MyModel(id=1) != MyModel(id=2)
# Primay keys are None
MyModel(id=None) != MyModel(id=None)
# Same instance
instance = MyModel(id=None)
instance == instance
# Proxy model
MyModel(id=1) == MyProxyModel(id=1)
# Multi-table inheritance
MyModel(id=1) != MultitableInherited(id=1)
__hash__()
¶
The __hash__()
method is based on the instance’s primary key value. It
is effectively hash(obj.pk)
. If the instance doesn’t have a primary key
value then a TypeError
will be raised (otherwise the __hash__()
method would return different values before and after the instance is
saved, but changing the __hash__()
value of an instance is
forbidden in Python.
get_absolute_url()
¶
-
Model.
get_absolute_url
()¶
Define a get_absolute_url()
method to tell Django how to calculate the
canonical URL for an object. To callers, this method should appear to return a
string that can be used to refer to the object over HTTP.
For example:
def get_absolute_url(self):
return "/people/%i/" % self.id
While this code is correct and simple, it may not be the most portable way to
to write this kind of method. The reverse()
function is
usually the best approach.
For example:
def get_absolute_url(self):
from django.urls import reverse
return reverse('people.views.details', args=[str(self.id)])
One place Django uses get_absolute_url()
is in the admin app. If an object
defines this method, the object-editing page will have a 「View on site」 link
that will jump you directly to the object’s public view, as given by
get_absolute_url()
.
Similarly, a couple of other bits of Django, such as the syndication feed
framework, use get_absolute_url()
when it is
defined. If it makes sense for your model’s instances to each have a unique
URL, you should define get_absolute_url()
.
警告
You should avoid building the URL from unvalidated user input, in order to reduce possibilities of link or redirect poisoning:
def get_absolute_url(self):
return '/%s/' % self.name
If self.name
is '/example.com'
this returns '//example.com/'
which, in turn, is a valid schema relative URL but not the expected
'/%2Fexample.com/'
.
It’s good practice to use get_absolute_url()
in templates, instead of
hard-coding your objects』 URLs. For example, this template code is bad:
<!-- BAD template code. Avoid! -->
<a href="/people/{{ object.id }}/">{{ object.name }}</a>
This template code is much better:
<a href="{{ object.get_absolute_url }}">{{ object.name }}</a>
The logic here is that if you change the URL structure of your objects, even
for something simple such as correcting a spelling error, you don’t want to
have to track down every place that the URL might be created. Specify it once,
in get_absolute_url()
and have all your other code call that one place.
注釈
The string you return from get_absolute_url()
must contain only
ASCII characters (required by the URI specification, RFC 2396) and be
URL-encoded, if necessary.
Code and templates calling get_absolute_url()
should be able to use the
result directly without any further processing. You may wish to use the
django.utils.encoding.iri_to_uri()
function to help with this if you
are using unicode strings containing characters outside the ASCII range at
all.
Extra instance methods¶
In addition to save()
, delete()
, a model object
might have some of the following methods:
-
Model.
get_FOO_display
()¶
For every field that has choices
set, the
object will have a get_FOO_display()
method, where FOO
is the name of
the field. This method returns the 「human-readable」 value of the field.
For example:
from django.db import models
class Person(models.Model):
SHIRT_SIZES = (
('S', 'Small'),
('M', 'Medium'),
('L', 'Large'),
)
name = models.CharField(max_length=60)
shirt_size = models.CharField(max_length=2, choices=SHIRT_SIZES)
>>> p = Person(name="Fred Flintstone", shirt_size="L")
>>> p.save()
>>> p.shirt_size
'L'
>>> p.get_shirt_size_display()
'Large'
-
Model.
get_next_by_FOO
(**kwargs)¶
-
Model.
get_previous_by_FOO
(**kwargs)¶
For every DateField
and
DateTimeField
that does not have null=True
, the object will have get_next_by_FOO()
and
get_previous_by_FOO()
methods, where FOO
is the name of the field. This
returns the next and previous object with respect to the date field, raising
a DoesNotExist
exception when appropriate.
Both of these methods will perform their queries using the default manager for the model. If you need to emulate filtering used by a custom manager, or want to perform one-off custom filtering, both methods also accept optional keyword arguments, which should be in the format described in Field lookups.
Note that in the case of identical date values, these methods will use the primary key as a tie-breaker. This guarantees that no records are skipped or duplicated. That also means you cannot use those methods on unsaved objects.
Other attributes¶
DoesNotExist
¶
-
exception
Model.
DoesNotExist
¶ This exception is raised by the ORM in a couple places, for example by
QuerySet.get()
when an object is not found for the given query parameters.Django provides a
DoesNotExist
exception as an attribute of each model class to identify the class of object that could not be found and to allow you to catch a particular model class withtry/except
. The exception is a subclass ofdjango.core.exceptions.ObjectDoesNotExist
.