このドキュメントには、Django が提供するフィールドオプション field options とフィールド型 field types を含む、Field のすべての API リファレンスが記載されています。
以下の引数は全てのフィールドタイプで有効です。全て省略可能です。
\nnullLink to this heading#True の場合、Django はデータベース内に NULL として空の値を保持します。デフォルトは False です。
CharField や TextField などの文字列ベースのフィールドでは、 null の使用は避けてください。Django は習慣的に、文字列ベースのフィールドの「データなし」状態には NULL ではなく空文字列を用います。文字列ベースのフィールドが null=False の場合でも、「データなし」として空文字列は保存できます。 null=True の場合は、「データなし」を表す値が NULL と空文字列の 2 通りになります。多くの場合、「データなし」を表す値が 2 つあるのは冗長です。例外として、CharField に unique=True と blank=True の両方を設定する場合があります。この状況では、空文字列のオブジェクトを複数保存する際に一意制約違反を避けるため、 null=True が必要になります。
文字列ベースのフィールドでもそれ以外でも、フォーム内で空の値を許可したいときは blank=True を指定する必要があります。 null パラメーターはデータベースストレージにだけ影響を与えるからです（詳細は blank を参照）。
blankLink to this heading#True の場合、フィールドはブランクになることが許容されます。デフォルトは False です。
null とは異なる点に注意してください。null が純粋にデータベースに関連する一方で、blank はバリデーションに関連します。フィールドが blank=True を持つ場合、フォームバリデーションは空の値のエントリーを許容します。blank=False を持つ場合、フィールドは必須となります。
choicesLink to this heading#このフィールドの選択肢として使用するための、以下で説明する形式のマッピングまたはイテラブルです。choices が指定された場合、 モデルのバリデーション によって強制的に、デフォルトのフォームウィジェットが通常のテキストフィールドの代わりにこれらの選択肢を持つセレクトボックスになります。
\nマッピングが指定された場合、キー要素はモデルに設定される実際の値で、2番目の要素は人間が読める名前です。例えば
\nYEAR_IN_SCHOOL_CHOICES = {\n "FR": "Freshman",\n "SO": "Sophomore",\n "JR": "Junior",\n "SR": "Senior",\n "GR": "Graduate",\n}\nまた、 sequence として、ちょうど2つの項目からなるイテラブルを渡すこともできます (例 [(A1, B1), (A2, B2), ...])。各タプルの最初の要素はモデルに設定される実際の値で、2番目の要素は人間が読める名前です。例えば
YEAR_IN_SCHOOL_CHOICES = [\n ("FR", "Freshman"),\n ("SO", "Sophomore"),\n ("JR", "Junior"),\n ("SR", "Senior"),\n ("GR", "Graduate"),\n]\nまた、choices は、上記のいずれかのフォーマットを返す引数なしの呼び出し可能オブジェクトとして定義することもできます。例えば
def get_currencies():\n return {i: i for i in settings.CURRENCIES}\n\n\nclass Expense(models.Model):\n amount = models.DecimalField(max_digits=10, decimal_places=2)\n currency = models.CharField(max_length=3, choices=get_currencies)\nchoice に呼び出し可能オブジェクトを渡すと、例えば選択肢が以下のような場合に特に便利です：
同じデータベースや外部データベースのテーブルをクエリしたり、静的ファイルから選択肢にアクセスしたりするような、I/Oバウンド操作の結果（キャッシュされる可能性があります）。
ほぼ安定しているが、場合によって、あるいはプロジェクトによって異なる可能性のあるリスト。このカテゴリの例は、通貨、国、言語、タイムゾーンなど、よく知られた値のインベントリを提供するサードパーティのアプリを使用する場合などです。
一般的に、モデルクラスの内部で選択肢を定義し、それぞれの値に適切に名前づけられた定数を定義するのがベストです:
\nfrom django.db import models\n\n\nclass Student(models.Model):\n FRESHMAN = "FR"\n SOPHOMORE = "SO"\n JUNIOR = "JR"\n SENIOR = "SR"\n GRADUATE = "GR"\n YEAR_IN_SCHOOL_CHOICES = {\n FRESHMAN: "Freshman",\n SOPHOMORE: "Sophomore",\n JUNIOR: "Junior",\n SENIOR: "Senior",\n GRADUATE: "Graduate",\n }\n year_in_school = models.CharField(\n max_length=2,\n choices=YEAR_IN_SCHOOL_CHOICES,\n default=FRESHMAN,\n )\n\n def is_upperclass(self):\n return self.year_in_school in {self.JUNIOR, self.SENIOR}\nモデルクラスの外側で選択肢リストを定義し、それを参照することもできますが、モデルクラスの内側で選択肢と各選択肢の名前を定義することで、その情報を使用するクラスで保持し、選択肢を参照しやすくなります（例えば、Student.SOPHOMORE は Student モデルがインポートされていればどこでも動作します）。
利用可能な選択肢を、組織化のために名前付きグループにまとめることもできます。
\nMEDIA_CHOICES = {\n "Audio": {\n "vinyl": "Vinyl",\n "cd": "CD",\n },\n "Video": {\n "vhs": "VHS Tape",\n "dvd": "DVD",\n },\n "unknown": "Unknown",\n}\nマッピングのキーはグループに適用する名前であり、値はそのグループ内の選択肢で、フィールドの値とオプションの人間が読める名前からなります。グループ化されたオプションは、1つのマッピングの中でグループ化されていないオプションと組み合わせることができます（この例の "unknown" オプションのように）。
2値タプルのリストなど、シーケンスを使うこともできます：
\nMEDIA_CHOICES = [\n (\n "Audio",\n (\n ("vinyl", "Vinyl"),\n ("cd", "CD"),\n ),\n ),\n (\n "Video",\n (\n ("vhs", "VHS Tape"),\n ("dvd", "DVD"),\n ),\n ),\n ("unknown", "Unknown"),\n]\nなお、choices はリストやタプルである必要はなく、任意のシーケンスオブジェクトでも構いません。これにより、選択肢を動的に構築できます。しかし、 choices をハックして動的にするよりは、 ForeignKey を持つ適切なデータベーステーブルを使ったほうがいいでしょう。 choices はあまり変更されない静的なデータのためのものです。
choices が設定されている各モデルフィールドに対して、 Django は選択肢を2値タプルのリストに正規化し、フィールドの現在の値に対して、 人間が読める名前を取得するメソッドを追加します。データベース API ドキュメントの get_FOO_display() を参照してください。
フィールドに default とともに blank=False が指定されない限り、セレクトボックスには "---------" を含むラベルが表示されます。この動作をオーバーライドするには、たとえば (None, "表示したい文字列") のように None を含むタプルを choices に追加してください。もしくは、 None の代わりに空の文字列を使うこともできます。これは特に CharField などに適しています。
さらに Django には、選択肢を簡潔に定義するためにサブクラス化できる列挙型があります：
\nfrom django.utils.translation import gettext_lazy as _\n\n\nclass Student(models.Model):\n class YearInSchool(models.TextChoices):\n FRESHMAN = "FR", _("Freshman")\n SOPHOMORE = "SO", _("Sophomore")\n JUNIOR = "JR", _("Junior")\n SENIOR = "SR", _("Senior")\n GRADUATE = "GR", _("Graduate")\n\n year_in_school = models.CharField(\n max_length=2,\n choices=YearInSchool,\n default=YearInSchool.FRESHMAN,\n )\n\n def is_upperclass(self):\n return self.year_in_school in {\n self.YearInSchool.JUNIOR,\n self.YearInSchool.SENIOR,\n }\nこれらはPythonの標準ライブラリの enum と似たような動作をしますが、若干の変更が加えられています：
列挙型のメンバ値は、具象データ型を構築するときに使う引数のタプルです。Django はこのタプルの末尾に、人間が読める名前、つまり label として使われる文字列値を追加することをサポートしています。この label は遅延 (Lazy な) 翻訳が可能な文字列です。したがって、ほとんどの場合、メンバの値は (value, label) の2値タプルになります。より複雑なデータ型を使用した 選択肢のサブクラスの例 については以下を参照してください。タプルが提供されない場合、あるいは最後の項目が（lazyな）文字列でない場合、 label はメンバー名から 自動的に生成 されます。
値には .label プロパティが追加され、人間が読める名前を返します。
列挙型クラスには、 .choices, .labels, .values, .names などのカスタムプロパティが追加されており、これらの列挙型の異なる部分のリストに簡単にアクセスできるようになっています。
The use of enum.unique() is enforced to ensure that values cannot be\ndefined multiple times. This is unlikely to be expected in choices for a\nfield.
なお、 YearInSchool.SENIOR, YearInSchool['SENIOR'], YearInSchool('SR') を使用して列挙型のメンバにアクセスしたり、メンバの .name と .value プロパティを参照したりすることは期待通りに動作します。
人が読める名前を翻訳する必要がない場合は、メンバ名から推測してそれらを自動設定させることができます（アンダースコアをスペースに置き換え、タイトルケースを使用します）：
\n>>> class Vehicle(models.TextChoices):\n... CAR = "C"\n... TRUCK = "T"\n... JET_SKI = "J"\n...\n>>> Vehicle.JET_SKI.label\n'Jet Ski'\n列挙値が整数である必要があるケースは非常に多いので、Django は IntegerChoices クラスを用意しています。例えば
class Card(models.Model):\n class Suit(models.IntegerChoices):\n DIAMOND = 1\n SPADE = 2\n HEART = 3\n CLUB = 4\n\n suit = models.IntegerField(choices=Suit)\nまた、 Enum Functional API を利用することもできます。この場合、ラベルは上記のように自動的に生成されます：
\n>>> MedalType = models.TextChoices("MedalType", "GOLD SILVER BRONZE")\n>>> MedalType.choices\n[('GOLD', 'Gold'), ('SILVER', 'Silver'), ('BRONZE', 'Bronze')]\n>>> Place = models.IntegerChoices("Place", "FIRST SECOND THIRD")\n>>> Place.choices\n[(1, 'First'), (2, 'Second'), (3, 'Third')]\nもし int や str 以外の具象データ型のサポートが必要であれば、 Choices と必要な具象データ型、例えば date を DateField で使用するようにサブクラス化できます：
class MoonLandings(datetime.date, models.Choices):\n APOLLO_11 = 1969, 7, 20, "Apollo 11 (Eagle)"\n APOLLO_12 = 1969, 11, 19, "Apollo 12 (Intrepid)"\n APOLLO_14 = 1971, 2, 5, "Apollo 14 (Antares)"\n APOLLO_15 = 1971, 7, 30, "Apollo 15 (Falcon)"\n APOLLO_16 = 1972, 4, 21, "Apollo 16 (Orion)"\n APOLLO_17 = 1972, 12, 11, "Apollo 17 (Challenger)"\nさらに注意すべき点がいくつかあります：
\n列挙型は 名前付きグループ をサポートしていません。
具体的なデータ型を持つ列挙型では、すべての値がそのデータ型に一致する必要があるため、 blank label をオーバーライドする際に、 None という値を持つメンバを作成することはできません。代わりに、クラスに __empty__ 属性を設定します：
class Answer(models.IntegerChoices):\n NO = 0, _("No")\n YES = 1, _("Yes")\n\n __empty__ = _("(Unknown)")\ndb_columnLink to this heading#このフィールドを使用するためのデータベースのカラムの名前です。もし与えられなければ、Django はフィールド名を使用します。
\nデータベースのカラム名が SQL の予約語だったり、Python の変数名として使用できない文字 (特に多いのがハイフン) が含まれていたとしても大丈夫です。Django はカラムとテーブルの名前を自動的にクオートして処理してくれます。
\ndb_commentLink to this heading#このフィールドに使うデータベースカラムのコメントです。あなたの Django コードを見ていないような、データベースに直接アクセスできる人のために、フィールドをドキュメント化するのに便利です。例えば：
\npub_date = models.DateTimeField(\n db_comment="Date and time when the article was published",\n)\ndb_defaultLink to this heading#データベースによって計算されるこのフィールドのデフォルト値。これはリテラル値でも、 Now のようなデータベース関数でも構いません：
created = models.DateTimeField(db_default=Now())\nリテラルやデータベース関数から構成する限り、より複雑な式を使用できます：
\nmonth_due = models.DateField(\n db_default=TruncMonth(\n Now() + timedelta(days=90),\n output_field=models.DateField(),\n )\n)\nデータベースのデフォルトは、他のフィールドやモデルを参照することはできません。例えば、これは無効です：
\nend = models.IntegerField(db_default=F("start") + 50)\nもし db_default と Field.default の両方が指定された場合、Python コードでインスタンスを作成する際には default が優先されます。データベースレベルでも db_default が設定され、ORM の外部で行を挿入するときや、マイグレーションで新しいフィールドを追加するときに使用されます。
フィールドに db_default は設定されているが default が設定されておらず、フィールドに値が割り当てられていない場合、保存されていないモデルインスタンスでは DatabaseDefault オブジェクトがフィールドの値として返されます。フィールドの実際の値は、モデルインスタンスが保存されたときにデータベースによって決定されます。
db_indexLink to this heading#True の場合、データベースインデックスがこのフィールドのために生成されます。
db_tablespaceLink to this heading#このフィールドにインデックスが作成されている場合に、このフィールドのインデックスに使用する データベース テーブル空間 の名前です。デフォルトはプロジェクトの DEFAULT_INDEX_TABLESPACE が設定されている場合はその設定値、またはモデルの db_tablespace が設定されている場合はその設定値です。バックエンドがインデックスのテーブル空間をサポートしていない場合、このオプションは無視されます。
defaultLink to this heading#そのフィールドのデフォルト値です。このオプションには特定の値もしくは呼び出し可能オブジェクトを渡すことができます。もし渡した値が呼び出し可能であれば新しくオブジェクトが生成される度に呼び出されます。
\nデフォルト値はミュータブルなオブジェクト（モデルのインスタンス、 list 、 set など）にはできません。そのオブジェクトの同じインスタンスへの参照が、すべての新しいモデルインスタンスのデフォルト値として使用されてしまうからです。代わりに、必要なデフォルト値を呼び出し可能オブジェクトでラップします。例えば、 JSONField に対してデフォルトの dict を指定したい場合、下記のような関数を使用します：
def contact_default():\n return {"email": "to1@example.com"}\n\n\ncontact_info = JSONField("ContactInfo", default=contact_default)\nlambda は マイグレーションでシリアライズ できないので、default のようなフィールドオプションには使えません。その他の注意点についてはドキュメントを参照してください。
ForeignKey のようにモデルインスタンスにマッピングされるフィールドの場合、デフォルトはモデルインスタンスではなく、参照するフィールドの値 (to_field が設定されていない限り pk) になります。
デフォルト値は、新しいモデルインスタンスが作成され、フィールドに値が提供されていない場合に使用されます。フィールドが主キーの場合、フィールドが None に設定されているときにもデフォルト値が使われます。
デフォルト値は Field.db_default でデータベースレベルで設定することもできます。
editableLink to this heading#False の場合、フィールドは管理サイトやその他の ModelForm において表示されません。このとき model validation の過程でもスキップされます。デフォルトは True です。
error_messagesLink to this heading#引数 error_messages を指定すると、フィールドが表示するデフォルトのメッセージを上書きできます。オーバーライドしたいエラーメッセージにマッチするキーを持つ辞書を渡してください。
エラーメッセージのキーには null, blank, invalid, invalid_choice, unique, unique_for_date があります。以下の Field types セクションで説明する各フィールドには、追加のエラーメッセージキーが指定されています。
これらのエラーメッセージはフォームに反映されないことがよくあります。詳細は モデルの error_messages についての注意 を参照してください。
\nhelp_textLink to this heading#フォームウィジェットと共に表示される "補助" テキストになります。この値はフィールドがフォームとして利用されない場合でもドキュメント化する際に有用です。
\nこの値は自動生成のフォームではHTMLエスケープ されません 。そのため、 help_text にはHTMLが使えます。例：
help_text = "Please use the following format: <em>YYYY-MM-DD</em>."\nあるいは、プレーンテキストを使い、 django.utils.html.escape() で HTML の特殊文字をエスケープすることもできます。クロスサイトスクリプティング攻撃を避けるために、信頼できないユーザから来る可能性のあるヘルプテキストは必ずエスケープしてください。
primary_keyLink to this heading#True の場合、設定したフィールドはそのモデルの主キーとなります。
モデル内のいずれのフィールドにも primary_key=True を指定せず、かつ複合主キーを定義していない場合、 Django は主キーを保持するためのフィールドを自動的に追加します。したがって、既定の主キー動作を上書きしたくなければ、どのフィールドにも primary_key=True を設定する必要はありません。自動作成される主キーの型は、アプリ単位では AppConfig.default_auto_field 、グローバルには DEFAULT_AUTO_FIELD 設定で指定できます。詳しくは 自動インクリメントの主キーフィールド を参照してください。
primary_key=True は null=False および unique=True を含意します。1 つのモデルで primary_key=True を設定できるフィールドは 1 つだけです。この不変条件を維持するため、複合主キーは、すべてのフィールドにこのフラグを True と設定するのではなく、CompositePrimaryKey を使用して定義しなければなりません。
主キーフィールドは読み取り専用です。既存のオブジェクトの主キーの値を変更して保存すると、古いオブジェクトはそのままで新しいオブジェクトが作成されます。
\nオブジェクトを 削除する 際に、主キーフィールドは None に設定されます。
uniqueLink to this heading#True の場合、そのフィールドはテーブル上で一意となる制約を受けます。
これはデータベースレベルとモデルのバリデーションで強制されます。 unique フィールドの値が重複しているモデルを保存しようとすると、モデルの save() メソッドによって django.db.IntegrityError が発生します。
このオプションは ManyToManyField と OneToOneField 以外の全てのフィールドタイプで有効です。
unique が True の場合、db_index を指定する必要はないことに注意してください。なぜなら unique がインデックスの作成を意味するからです。
unique_for_dateLink to this heading#これを DateField または DateTimeField の名前に設定すると、このフィールドが日付フィールドの値に対して一意であることを要求します。
例えば、 title フィールドに unique_for_date="pub_date" を指定した場合、 Django は同じ title と pub_date を持つ 2 つのレコードの入力を許可しません。
DateTimeField を指すように設定した場合は、フィールドの日付部分のみが考慮されることに注意してください。また、 USE_TZ が True の場合、オブジェクトの保存時に カレントタイムゾーン でチェックが行われます。
This is enforced by Model.validate_unique() during model validation\nbut not at the database level. If any unique_for_date constraint\ninvolves fields that are not part of a ModelForm (for\nexample, if one of the fields is listed in exclude or has\neditable=False), Model.validate_unique() will\nskip validation for that particular constraint.
unique_for_monthLink to this heading#unique_for_date と似ていますが、フィールドが月に対して一意である必要があります。
unique_for_yearLink to this heading#unique_for_date や unique_for_month と同様です。
verbose_nameLink to this heading#人間が読めるフィールド名。verbose な名前が指定されていない場合、 Django はフィールドの属性名を使って自動的にフィールドを作成し、アンダースコアをスペースに変換します。詳しくは verbose なフィールド名 を参照してください。
\nvalidatorsLink to this heading#このフィールドに対して実行するバリデータのリスト。詳細は バリデータのドキュメント を参照してください。
\nAutoFieldLink to this heading#利用可能な ID に応じて、自動的にインクリメントする IntegerField です。通常は直接使う必要はありません; 指定しない場合は、主キーのフィールドが自動的にモデルに追加されます。自動インクリメントの主キーフィールド も参照してください。
BigAutoFieldLink to this heading#64 ビットの数値です。1 から 9223372036854775807 までの数を扱える以外は、AutoField と同じです。
BigIntegerFieldLink to this heading#64 ビットの整数で、 IntegerField とよく似ていますが、 -9223372036854775808 から 9223372036854775807 までの数値が入ることが保証されています。このフィールドのデフォルトのフォームウィジェットは NumberInput です。
BinaryFieldLink to this heading#生のバイナリデータを格納するフィールドです。 bytes, bytearray または memoryview を指定できます。
デフォルトでは、 BinaryField は editable を False に設定します。この場合、 ModelForm に含めることはできません。
オプション。フィールドの最大長 (バイト単位)。最大長は MaxLengthValidator を使ったDjango のバリデーションで強制されます。
BooleanFieldLink to this heading#true/false のフィールドです。
\nこのフィールドのデフォルトのフォームウィジェットは CheckboxInput で、 null=True の場合は NullBooleanSelect です。
Field.default が定義されていないときの BooleanField のデフォルト値は None です。
CompositePrimaryKeyLink to this heading#複合主キーを定義するために用いられる仮想的なフィールドです。
\nこのフィールドはモデルの pk 属性として定義しなければなりません。これが存在する場合、 Django は基盤となるモデルテーブルを複合主キーで作成します。
*field_names 引数は主キーを構成する位置フィールド名のリストです。
詳細は 複合主キー を参照してください。
\nCharFieldLink to this heading#小 - 大サイズの文字列のフィールドです。
\n多量のテキストを扱うときは TextField を使ってください。
このフィールドのデフォルトのフォームウィジェットは TextInput です。
CharField には以下の追加引数があります：
フィールドの（文字数の）最大値。 max_length はデータベース層および class:~django.core.validators.MaxLengthValidator を使用した Django のバリデーションによる制約を受けます。無制限の VARCHAR 列をサポートする PostgreSQL と SQLite を除き、 Django でサポートされるすべてのデータベースバックエンドにおいて必須です。
オプション。フィールドのデータベース照合順序名(collation name)です。
\n\n\nDateFieldLink to this heading#Python で datetime.date インスタンスによって表される日付です。多少の追加的な省略可能な引数を持ちます:
オブジェクトが保存される度に自動的に現在の日付をセットします。"最後の変更" タイムスタンプに役立ちます。現在の日付が常に使われる点に注意してください; オーバーライドできる単なるデフォルト値ではありません。
\nModel.save() が呼ばれたとき、フィールドは自動的に更新されるだけです。QuerySet.update() のような別の方法で他のフィールドに更新を加えるとき、フィールドは更新されません。あのように更新の中でフィールドの独自の値を指定できるとしてもです。
オブジェクトが最初に作成されるとき、自動的にフィールドに現在の日付をセットします。タイムスタンプの作成に役立ちます。現在の日付が 常に 使われる点に注意してください; オーバーライドできる単なるデフォルト値ではありません。たとえオブジェクトを作成するときに値をセットしたとしても無視されます。このフィールドを修正できるようにしておきたい場合は、auto_now_add=True の代わりに以下をセットしてください:
DateField に対して: default=date.today - datetime.date.today() より
DateTimeField に対して: default=timezone.now - django.utils.timezone.now() より
このフィールドのデフォルトのフォームウィジェットは DateInput です。admin は JavaScript カレンダーと "Today" のショートカットを追加します。追加の invalid_date エラーメッセージキーを含みます。
オプション auto_now_add、auto_now、default は相互に排他的です。これらのオプションを組み合わせるとエラーが発生します。
DateTimeFieldLink to this heading#Python で datetime.datetime インスタンスによって表される日付と時刻です。DateField と同じくいくつかの追加的な引数を持ちます:
このフィールドのデフォルトのフォームウィジェットは DateTimeInput です。管理画面では、JavaScript のショートカットを使って TextInput ウィジェットを 2 つに分けて使用します。
DecimalFieldLink to this heading#固定精度の10進数で、Python では Decimal インスタンスで表されます。これは DecimalValidator を使用して入力を検証します。
以下の 必須の 引数があります：
\n数値内で使える桁数の最大値です。 decimal_places 以上でなければならない点に注意してください。
数値とともに保持される小数点以下の位の数です。
\n例えば、小数点以下2桁の分解能で 999.99 までの数値を保存するには、次のようにします：
models.DecimalField(..., max_digits=5, decimal_places=2)\n小数点以下第10位の精度で約10億までを保持するには:
\nmodels.DecimalField(..., max_digits=19, decimal_places=10)\nこのフィールドのデフォルトのフォームウィジェットは、localize が False のとき NumberInput で、そうでなければ TextInput となります。
DurationFieldLink to this heading#時刻の期間を保持するフィールドで、 Python の timedelta によってモデル化されます。PostgreSQL で使われるときに用いられるデータ型は interval で、Oracle でのデータ型は INTERVAL DAY(9) TO SECOND(6) です。 それ以外では、マイクロ秒の bigint が使われます。
EmailFieldLink to this heading#EmailValidator を使って、値が有効なメールアドレスであるかどうかをチェックする CharField です。
FileFieldLink to this heading#ファイルアップロードのフィールドです。
\n\n以下のオプション引数があります：
\nこの属性は、アップロードディレクトリとファイル名を設定する方法を提供し、2 つの方法でセットできます。どちらの場合も、値は Storage.save() メソッドに渡されます。
文字列値または Path を指定する場合、 strftime() フォーマットを含むことができます。これはファイルアップロードの日時に置き換えられます（アップロードされたファイルで指定されたディレクトリが一杯にならないようにするためです）。例えば以下のようにします：
class MyModel(models.Model):\n # file will be uploaded to MEDIA_ROOT/uploads\n upload = models.FileField(upload_to="uploads/")\n # or...\n # file will be saved to MEDIA_ROOT/uploads/2015/01/30\n upload = models.FileField(upload_to="uploads/%Y/%m/%d/")\nデフォルトの FileSystemStorage を使用している場合、この文字列の値が MEDIA_ROOT パスに追加され、アップロードされたファイルが保存されるローカルファイルシステムの場所になります。別のストレージを使用している場合は、そのストレージのドキュメントで upload_to の扱い方を確認してください。
upload_to は関数のなどの呼び出し可能オブジェクトにすることもできます。これはファイル名を含むアップロードパスを取得するために呼び出されます。この呼び出し可能オブジェクトは2つの引数を受け取り、ストレージシステムに渡すUnixスタイルのパス（フォワードスラッシュ付き）を返さなければなりません。2つの引数は
引数 | \n説明 | \n
|---|---|
| \n
ほとんどの場合、このオブジェクトはまだデータベースに保存されていないため、デフォルトの | \n
| \nファイルに元々与えられていたファイル名。これは、最終的な宛先パスを決定するときに考慮されることもあれば、考慮されないこともあります。 | \n
例:
\ndef user_directory_path(instance, filename):\n # file will be uploaded to MEDIA_ROOT/user_<id>/<filename>\n return "user_{0}/{1}".format(instance.user.id, filename)\n\n\nclass MyModel(models.Model):\n upload = models.FileField(upload_to=user_directory_path)\nストレージオブジェクト、またはストレージオブジェクトを返す呼び出し可能オブジェクトです。これはファイルの保存と取得を行います。このオブジェクトの渡し方の詳細については ファイルの管理 を参照してください。
\nこのフィールドのデフォルトのフォームウィジェットは ClearableFileInput です。
モデル内で a FileField や ImageField (後述) 使うにはいくつかのステップを取ります:
設定ファイルでは、 MEDIA_ROOT を Django にアップロードされたファイルを保存するディレクトリへのフルパスを指定する必要があります（パフォーマンス上、これらのファイルはデータベースには保存されません）。 MEDIA_URL をそのディレクトリの公開 URL にします。このディレクトリは Web サーバのユーザアカウントで書き込み可能である必要があります。
モデルに FileField または ImageField を追加し、 upload_to オプションを定義して、ファイルをアップロードする MEDIA_ROOT のサブディレクトリを指定します。
データベースに保存されるのは、ファイルへのパス (MEDIA_ROOT からの相対パス) だけです。Django 組み込みの url 属性を使うと便利です。例えば、 ImageField が mug_shot という名前の場合、 {{ object.mug_shot.url }} でテンプレート内の画像の絶対パスを取得できます。
例えば、 MEDIA_ROOT が '/home/media' に設定され、 upload_to が 'photos/%Y/%m/%d' に設定されているとします。 upload_to の '%Y/%m/%d' の部分は strftime() フォーマットです。'%Y' は4桁の年、'%m' は2桁の月、'%d' は2桁の日です。2007年1月15日にファイルをアップロードすると、 /home/media/photos/2007/01/15 というディレクトリに保存されます。
アップロードされたファイルのディスク上のファイル名やファイルサイズを取得したい場合は、それぞれ name 属性と size 属性を使うことができます。利用可能な属性やメソッドの詳細については File クラスリファレンス と ファイルの管理 トピックガイド を参照してください。
アップロードされたファイルの相対URLは url 属性で取得できます。内部的には、 Storage クラスの url() メソッドを呼び出します。
アップロードされたファイルを扱うときは常に、セキュリティホールを避けるために、アップロードする場所とファイルの種類に細心の注意を払う必要があることに注意してください。 アップロードされたすべてのファイルを検証し 、そのファイルがあなたが考えているものであることを確認してください。例えば、誰かがあなたのウェブサーバーのドキュメントルートにあるディレクトリに、検証なしでファイルをアップロードするのをやみくもに許可すると、誰かがCGIやPHPスクリプトをアップロードし、あなたのサイトのそのURLにアクセスしてスクリプトを実行できます。それを許してはいけません。
\nまた、アップロードされたHTMLファイルであっても、ブラウザが実行できるため（サーバは実行できませんが）、XSS攻撃やCSRF攻撃と同様のセキュリティ上の脅威をもたらす可能性があることに注意してください。
\nFileField インスタンスは varchar カラムとしてデータベースに作成され、デフォルトの最大長は100文字です。他のフィールドと同様に、 max_length 引数を使用して最大長を変更できます。
FileField と FieldFileLink to this heading#モデル上の FileField にアクセスするとき、元となるファイルにアアクセスするためのプロキシとして、FieldFile のインスタンスが与えられます。
FieldFile の API は File の API を反映していますが、主な違いが 1 つあります: クラスによってラップされたオブジェクトは必ずしも Python のビルトインのファイルオブジェクトのラッパーであるとは限りません。 代わりに、Storage.open() メソッドの結果を包むラッパーで、これは File オブジェクトもしくは File API の独自ストレージの実装となります。
read() や write() など、File から継承されたAPIに加えて、FieldFile には基になるファイルとやり取りするために使用できるいくつかのメソッドが含まれています：
関連する FileField の Storage のルートからの相対パスを含むファイル名です。
ファイルのローカルファイルシステムパスにアクセスするための読み取り専用プロパティ。基になる Storage クラスの path() メソッドを呼び出します。
元となる Storage.size() メソッドの結果です。
元となる Storage クラス の url() メソッドを呼ぶことによって、ファイルの相対 URL にアクセスするための読み取り専用プロパティです。
このインスタンスに関連付けられたファイルを、指定された モード で開くか、開き直します。標準の Python の open() メソッドとは違い、ファイルのデスクリプタを返しません。
元となるファイルはアクセスするときに暗黙的に開かれるので、元となるファイルにポインタをリセットするためか モード を変更するため以外には、このメソッドを呼ぶ必要はないでしょう。
標準の Python の file.close() メソッドのように動作し、このインスタンスに関連付けられたファイルを閉じます。
このメソッドは、ファイル名とファイルの内容を取り、それらをフィールドのストレージクラスに渡し、格納されたファイルをモデルフィールドに関連付けます。 手動でファイルデータをモデル上の FileField インスタンスに関連付けるには、 save() メソッドを使用してそのファイルデータを保持します。
Takes two required arguments: name which is the name of the file, and\ncontent which is an object containing the file's contents. The\noptional save argument controls whether or not the model instance is\nsaved after the file associated with this field has been altered. Defaults to\nTrue.
content 引数は、Python のビルトインのファイルオブジェクトではなく、django.core.files.File のインスタンスでなければならないことに注意してください。 以下のように、既存の Python ファイルオブジェクトから File を構築できます:
from django.core.files import File\n\n# Open an existing file using Python's built-in open()\nf = open("/path/to/hello.world")\nmyfile = File(f)\nもしくは、以下のように Python の文字列から構築することもできます:
\nfrom django.core.files.base import ContentFile\n\nmyfile = ContentFile("hello world")\nより詳しくは ファイルの管理 を参照してください。
\nこのインスタンスに関連付けられているファイルを削除し、フィールドのすべての属性をクリアします。 注: このメソッドは、delete() が呼び出されたときにファイルが開いた場合、ファイルを閉じます。
省略可能な save 引数は、このフィールドに関連付けられたファイルが削除された後にモデルインスタンスを保存するかどうかをコントロールします。 デフォルトは True です。
モデルを削除するとき、関連ファイルは削除されない点に注意してください。 孤立したファイルをクリーンアップする必要がある場合、自分で処理する必要があります (たとえば、手動で実行したり、cron などを通して定期的に実行される独自の管理コマンドです)。
\nFilePathFieldLink to this heading#CharField は選択肢をファイルシステム上の特定のディレクトリにあるファイル名に限定します。いくつかの特別な引数を持ちますが、最初の引数は 必須 です：
必須です。FilePathField が選択肢から取得するディレクトリへの、ファイルシステムの絶対パスです。例: "/home/images"。
path には呼び出し可能オブジェクトを指定することもでき、これは例えば実行時に動的にパスを設定する関数などです。例：
import os\nfrom django.conf import settings\nfrom django.db import models\n\n\ndef images_path():\n return os.path.join(settings.LOCAL_FILE_DIR, "images")\n\n\nclass MyModel(models.Model):\n file = models.FilePathField(path=images_path)\n省略可能です。正規表現で、文字列として、FilePathField がファイル名をフィルタリングするために使用します。 正規表現は、フルパスではなくベースファイル名に適用される点に注意してください。 例: "foo.*\\.txt$"。これは foo23.txt とは合致しますが、bar.txt や foo23.png とは合致しません。
省略可能です。True か False のどちらかを取り、デフォルトは False です。path の全てのサブディレクトリを含むかどうかを指定します。
Optional. Either True or False. Default is True. Specifies\nwhether files in the specified location should be included. Either this or\nallow_folders must be True.
Optional. Either True or False. Default is False. Specifies\nwhether folders in the specified location should be included. Either this\nor allow_files must be True.
1つの可能性は、フルパスではなく、ベースファイル名に match が適用されることです。 したがって、この例:
FilePathField(path="/home/images", match="foo.*", recursive=True)\n...は、/home/images/foo/bar.png ではなく /home/images/foo.png とマッチします。これは、match がベースのファイル名に適用されるからです (foo.png と bar.png)。
FilePathField のインスタンスは、デフォルトが最大 100 文字の varchar カラムとして、データベース上に生成されます。他のフィールドと同様に、max_length 引数を使って最大文字数を変更できます。
FloatFieldLink to this heading#float インスタンスによって表される Python の浮動小数点数です。
このフィールドのデフォルトのフォームウィジェットは、localize が False のとき NumberInput で、そうでなければ TextInput となります。
GeneratedFieldLink to this heading#常にモデル内の他のフィールドに基づいて計算されるフィールド。このフィールドはデータベース自身によって管理・更新されます。 GENERATED ALWAYS SQL 構文を使います。
生成カラムには、格納と仮想の2種類があります。格納生成カラムは書き込まれる (挿入もしくは更新される) ときに計算され、通常のカラムと同じようにストレージを占有します。仮想生成カラムはストレージを占有せず、読み込まれるときに計算されます。したがって、仮想生成カラムはビューに似ており、格納生成カラムはマテリアライズド・ビューに似ています。
\nモデルが変更されるたびにフィールドの値を自動的に設定するためにデータベースによって使用される Expression 。
式は決定論的でなければならず、モデル内の（同じデータベース・テーブル内の）フィールドだけを参照しなければなりません。生成フィールドは他の生成フィールドを参照することはできません。データベースのバックエンドはさらなる制限を課すことができます。
\nフィールドのデータ型を定義するモデルフィールドインスタンス。
\nデータベースカラムが実際のカラムのようにストレージを占有するかどうかを決定します。 False の場合、カラムは仮想カラムとして動作し、データベースのストレージ領域を占有しません。
PostgreSQLは永続化 (persist) 列のみをサポートしています。Oracle は仮想列のみをサポートしています。
\nGenericIPAddressFieldLink to this heading#IPv4 か IPv6 のアドレスで、文字列フォーマットです (例: 192.0.2.30 ないし 2a02:42fe::4)。このフィールドのデフォルトのフォームウィジェットは TextInput です。
IPv6 アドレスは、 RFC 4291 Section 2.2 section 2.2 (同セクションの paragraph 3 で提案された IPv4 のフォーマットの使用を含む) にしたがって、 ::ffff:192.0.2.0 のように正規化します。たとえば、 2001:0::0:01 は 2001::1 と正規化され、 ::ffff:0a0a:0a0a は ::ffff:10.10.10.10 と正規化されます。そして、すべての文字は小文字に変換されます。
有効なインプットを、指定したプロトコルに制限します。 使用可能な値は 'both' (デフォルト)、'IPv4'、'IPv6' のどれかです。マッチングは大文字と小文字を区別しません。
IPv4 にマッピングされた ::ffff:192.0.2.1 のようなアドレスをアンパックします。このオプションを有効にすると、このアドレスは 192.0.2.1 とアンパックされます。デフォルトは無効です。protocol が 'both' に設定されている場合にだけ使用できます。
ブランク値を要する場合、ブランク値は null として保持されるため、null 値を許容する必要があります。
\nImageFieldLink to this heading#FileField から全ての属性とメソッドを継承して、さらにアップロードされたオブジェクトが有効な画像であることを検証します。
FileField で使える専用の属性に加えて、ImageField には height と width 属性があります。
これらの属性に対するクエリを容易にするために、ImageField は以下のオプション引数を持ちます：
画像オブジェクトがセットされるたびに自動的に画像の高さが入力されるモデルフィールドの名前。
\n画像オブジェクトがセットされるたびに自動的に画像の幅が入力されるモデルフィールドの名前。
\npillow ライブラリを必要とします。
\nImageField のインスタンスは、デフォルトが最大 100 文字の varchar カラムとして、データベース上に生成されます。他のフィールドと同様に、max_length 引数を使って最大文字数を変更できます。
このフィールドのデフォルトのフォームウィジェットは ClearableFileInput です。
IntegerFieldLink to this heading#整数値です。特定範囲の値のみ使用可能です (その範囲はデータベースに依存します)。 -2147483648 から 2147483647 までの値は、Django がサポートするすべてのデータベースで安全に使用できます。
MinValueValidator と MaxValueValidator を使って、デフォルトのデータベースがサポートする値に基づいて入力を検証します。
このフィールドのデフォルトのフォームウィジェットは、localize が False のとき NumberInput で、そうでなければ TextInput となります。
JSONFieldLink to this heading#JSON エンコードされたデータを格納するためのフィールドです。Python では、データは Python ネイティブフォーマットで表現されます。辞書、リスト、文字列、数値、真偽値、そして None です。
JSONField はMariaDB、MySQL、Oracle、PostgreSQL、(JSON1 エクステンションが有効な) SQLite でサポートされています。
An optional json.JSONEncoder subclass to serialize data types\nnot supported by the standard JSON serializer (e.g. datetime.datetime\nor UUID). For example, you can use the\nDjangoJSONEncoder class.
デフォルトは json.JSONEncoder です。
An optional json.JSONDecoder subclass to deserialize the value\nretrieved from the database. The value will be in the format chosen by the\ncustom encoder (most often a string). Your deserialization may need to\naccount for the fact that you can't be certain of the input type. For\nexample, you run the risk of returning a datetime that was actually a\nstring that just happened to be in the same format chosen for\ndatetimes.
デフォルトは json.JSONDecoder です。
データベース内の JSONField をクエリするには、 JSONField へのクエリ を参照してください。
PositiveBigIntegerFieldLink to this heading#PositiveIntegerField とほぼ同じですが、特定の数以下の値のみ使用可能です (その上限はデータベースに依存します)。 0 から 9223372036854775807 までの値は、 Django がサポートする全てのデータベースで安全に使用できます。
PositiveIntegerFieldLink to this heading#IntegerField とほぼ同じですが、ゼロ( 0 )以上の整数で、特定の数以下の値のみ使用可能です (その上限はデータベースに依存します)。 0 から 2147483647 までの値は、 Django がサポートするすべてのデータベースで安全に使用できます。値 0 は後方互換性のために許容されています。
PositiveSmallIntegerFieldLink to this heading#class:PositiveIntegerField とほぼ同じですが、特定の数以下の値のみ使用可能です (その上限はデータベースに依存します)。 0 から 32767 までの値は、 Django がサポートする全てのデータベースで安全に使用できます。
SlugFieldLink to this heading#スラグ (slug) は新聞用語です。スラグとは、アルファベット、数字、アンダースコア、またはハイフンのみを含む、何かの短いラベルです。一般的にURLで使われます。
\nCharField のように、max_length を指定することもできます (データベースの可搬性についてのノートとそのセクションの max_length も参照してください)。max_length が指定されていないとき、Django はデフォルトの文字数 50 を使います。
暗黙的に Field.db_index を True にセットします。
It is often useful to automatically prepopulate a SlugField based on the value\nof some other value. You can do this automatically in the admin using\nprepopulated_fields.
バリデーションには validate_slug または validate_unicode_slug を使用します。
True なら、フィールドはASCII文字に加えてUnicode文字も受け付けます。デフォルトは False です。
SmallAutoFieldLink to this heading#class:AutoField とほぼ同じですが、特定の数以下の値のみ使用可能です (その上限はデータベースに依存します)。 1 から 32767 までの値は、 Django がサポートする全てのデータベースで安全に使用できます。
SmallIntegerFieldLink to this heading#class:IntegerField とほぼ同じですが、特定の数以下の値のみ使用可能です (その上限はデータベースに依存します)。 -32768 から 32767 までの値は、 Django がサポートする全てのデータベースで安全に使用できます。
TextFieldLink to this heading#多量のテキストのフィールドです。このフィールドのデフォルトのフォームウィジェットは Textarea です。
max_length 属性を指定した場合、自動生成されたフォームフィールドの Textarea ウィジェット内で反映されます。ただし、モデルやデータベースのレベルでは施行されません。そのためには CharField を使用してください。
オプション。フィールドのデータベース照合順序名(collation name)です。
\n\n\nTimeFieldLink to this heading#Python で datetime.time インスタンスによって表される時刻です。DateField と同じ自動入力されるオプションを受け入れます。
このフィールドのデフォルトのフォームウィジェットは TimeInput です。admin はいくつかの JavaScript ショートカットを追加します。
URLFieldLink to this heading#URLの CharField で、 URLValidator によってバリデーションされます。
このフィールドのデフォルトのフォームウィジェットは URLInput です。
全ての CharField サブクラスと同じく、URLField は省略可能な max_length 引数を取ります。max_length を指定しない場合、デフォルトの 200 が使われます。
UUIDFieldLink to this heading#一意な識別子を格納するためのフィールドです。Python の UUID クラスを使用します。PostgreSQL と MariaDB 10.7+ で使用する場合、 uuid データ型で保存されます。
UUID は primary_key に代わる AutoField への良い選択肢です。 データベースはあなたのための UUID を生成しないため、 default を使うことが推奨されます:
import uuid\nfrom django.db import models\n\n\nclass MyUUIDModel(models.Model):\n id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)\n # other fields\nUUID のインスタンスではなく、呼び出し可能オブジェクト（カッコは書かない）を default に渡すことに注意してください。
フィールドはデータベーステーブルのカラムを表す抽象クラスです。Django はフィールドを使ってデータベーステーブルを作成したり (db_type())、 Python の型をデータベースにマッピングしたり (get_prep_value())、逆にしたり (from_db_value()) します。
したがって、フィールドは、特に モデル や クエリセット など、他のDjango APIにおける基本的な要素です。
モデルでは、フィールドはクラス属性としてインスタンス化され、特定のテーブルのカラムを表します (モデル 参照)。フィールドには null や unique といった属性と、 Django がフィールドの値をデータベース固有の値にマッピングするためのメソッドがあります。
フィールド Field は RegisterLookupMixin のサブクラスなので、 Transform と Lookup の両方を登録して QuerySet で使用できます (例: field_name__exact="foo") 。デフォルトでは全ての 組み込みのルックアップ が登録されています。
CharField のような Django 組み込みのフィールドは全て Field の具体的な実装です。独自のフィールドが必要な場合は、組み込みフィールドをサブクラス化するか、一から Field を書いてください。どちらの場合でも カスタムのモデルフィールドを作成する を参照してください。
フィールドの詳細な説明。例えば django.contrib.admindocs アプリケーションなどのためのものです。
説明文は以下のような形式です：
\ndescription = _("String (up to %(max_length)s)")\n引数はフィールドの __dict__ から補間されます。
A class implementing the descriptor protocol\nthat is instantiated and assigned to the model instance attribute. The\nconstructor must accept a single argument, the Field instance.\nOverriding this class attribute allows for customizing the get and set\nbehavior.
フィールド Field をデータベース固有の型にマッピングするために、 Django はいくつかのメソッドを公開しています：
バックエンド固有の目的のために、このフィールドの名前を文字列で返します。デフォルトでは、クラス名を返します。
\nカスタムフィールドでの使用法については 組み込みフィールド・タイプのエミュレート を参照してください。
\nField のデータベースカラムのデータ型を、connection を考慮して返します。
カスタムフィールドでの使用法については カスタムデータベースタイプ を参照してください。
\nField を指す ForeignKey や OneToOneField などのフィールドのデータベースカラムのデータ型を、connection を考慮して返します。
カスタムフィールドでの使用法については カスタムデータベースタイプ を参照してください。
\nDjango がデータベースのバックエンドやフィールドとやり取りする必要がある場面は、 主に3つあります：
\nデータベースへのクエリ時 (Python の値 -> データベースのバックエンドの値)
データベースからデータを読み込むとき (データベースのバックエンドの値 -> Python の値)
データベースへの保存時 (Python の値 -> データベースのバックエンドの値)
クエリでは get_db_prep_value() と get_prep_value() が使用されます：
value はモデルの属性の現在の値で、メソッドはクエリのパラメータとして使用できるように書かれた形式のデータを返す必要があります。
使い方は Python オブジェクトをクエリ変数に変換する を参照してください。
\nConverts value to a backend-specific value. By default it returns\nvalue if prepared=True, and get_prep_value(value) otherwise.
使い方は クエリの変数をデータベースの変数に変換する を参照してください。
\nデータを読み込む際には from_db_value() が使用されます：
データベースが返す値を Python オブジェクトに変換します。これは get_prep_value() の逆です。
データベースのバックエンドはすでに正しい Python 型を返すか、バックエンド自身が変換を行うので、このメソッドはほとんどの組み込みフィールドには使われません。
\nexpression は self と同様です。
使い方は 変数を Python オブジェクトに変換する を参照してください。
\n\n保存時には pre_save() と get_db_prep_save() が使用されます：
get_db_prep_value() と同じですが、フィールドの値をデータベースに 保存 しなければならない場合に呼び出されます。デフォルトでは get_db_prep_value() を返します。
保存する前に値を整えるために get_db_prep_save() の前に呼び出されるメソッドです (例えば DateField.auto_now の場合など)。
model_instance はこのフィールドが属するインスタンスで、add はインスタンスが初めてデータベースに保存されるかどうかです。
このフィールドの model_instance からは適切な属性の値を返す必要があります。属性名は self.attname にあります (これは Field で設定します)。
使い方は 保存する前に値を前処理する場合 を参照してください。
\nフィールドは多くの場合、シリアライズやフォームから別の型として値を受け取ります。
\n値を正しい Python オブジェクトに変換します。これは value_to_string() の逆として動作し、 clean() でも呼び出されます。
使い方は 変数を Python オブジェクトに変換する を参照してください。
\nデータベースに保存する方法だけでなく、フィールドはその値をシリアライズする方法も知っておく必要があります：
\n指定されたモデルのインスタンスのフィールドの値を返します。
\nこのメソッドは value_to_string() でよく使われます。
obj を文字列に変換します。フィールドの値をシリアライズするために使用します。
使い方は シリアライズするためにフィールドデータを変換する場合 を参照してください。
\nモデルフォーム を使用する場合、 Field はどのフォームフィールドで表現されるべきかを知る必要があります：
このフィールドの ModelForm に対するデフォルトの django.forms.Field を返します。
formfield() がオーバーライドされて None を返すようになった場合、このフィールドは ModelForm から除外されます。
デフォルトでは、 form_class と choices_form_class の両方が None の場合、 CharField を使用します。フィールドに choices が指定されていて、 choices_form_class が指定されていない場合、 TypedChoiceField を使用します。
使い方は モデルフィールドのフォームフィールドの指定 を参照してください。
\nフィールドを再作成するのに十分な情報を持つ4値タプルを返します：
\nモデルのフィールド名。
フィールドのインポートパス (例 "django.db.models.IntegerField")。移植性は高く保つべきなので、あまり特定しすぎない方が良いかもしれません。
位置引数のリスト。
キーワード引数の辞書。
1.7 より前のバージョンでは、 マイグレーション を使用してデータをマイグレーションするために、このメソッドをフィールドに追加する必要がありました。
\nフィールド Field は ルックアップ レジストレーション API を実装しています。このAPIを使用して、フィールドクラスとそのインスタンスでどのルックアップを利用できるか、またフィールドからどのようにルックアップを取得するかをカスタマイズできます。
すべての Field インスタンスには、その動作を詳しく調べるための属性がいくつか含まれています。フィールドの機能に依存するコードを書く必要がある場合には、 isinstance チェックの代わりにこれらの属性を使用してください。これらの属性は Model._meta API と一緒に使うことで、特定のフィールドタイプを絞り込むことができます。カスタムモデルフィールドはこれらのフラグを実装する必要があります。
モデル継承で使用される OneToOneField のように、フィールドが自動的に作成されたかどうかを示す真偽値フラグ。
フィールドにデータベース・カラムが関連付けられているかどうかを示す真偽値。
\nデフォルトでは Options.get_fields() によって返されない隠しフィールドがあるかどうかを示す真偽値のフラグです。例えば、 ForeignKey の逆フィールドで、 related_name が '+' で始まる場合です。
真偽値フラグで、フィールドが機能のために一つまたは複数の他のモデルへの参照を含んでいるかどうかを示します（例: ForeignKey, ManyToManyField, OneToOneField など）。
フィールドが定義されているモデルを返します。フィールドがモデルの基底クラスに定義されている場合、model はインスタンスのクラスではなく基底クラスを参照します。
これらの属性はリレーションのカーディナリティやその他の詳細をクエリするために使用されます。これらの属性は全てのフィールドに存在しますが、フィールドがリレーションタイプである場合のみ (None ではなく) 真偽値を持ちます (Field.is_relation=True)。
真偽値フラグで、フィールドが多対多のリレーションを持つ場合は True となり、そうでない場合は False となります。Django で True となるフィールドは ManyToManyField だけです。
真偽値フラグで、フィールドが ForeignKey のような多対一のリレーションを持っている場合は True となり、そうでない場合は False となります。
真偽値フラグで、フィールドが GenericRelation や ForeignKey のような一対多のリレーションを持っている場合は True となり、そうでない場合は False となります。
真偽値フラグで、フィールドが OneToOneField のような一対一のリレーションを持っている場合は True となり、そうでない場合は False となります。
フィールドのリレーション先となるモデルを指定します。例えば、 ForeignKey(Author, on_delete=models.CASCADE) の Author です。 GenericForeignKey の related_model は常に None です。