このドキュメントには、フィールドオプションおよびフィールドタイプ Djangoが提供するフィールドのすべてのAPIリファレンスが含まれています。
も参照してください
組み込みフィールドでうまくいかない場合は、 django-localflavor （ documentation ）を試すことができます。これには、特定の国や文化に役立つさまざまなコードが含まれています。
また、独自のカスタムモデルフィールドを簡単に作成できます。
ノート
技術的には、これらのモデルは django.db.models.fields で定義されていますが、便宜上、 django.db.models にインポートされています。 標準の規則では、from django.db import modelsを使用し、フィールドをmodels.<Foo>Fieldと呼びます。
次の引数は、すべてのフィールドタイプで使用できます。 すべてオプションです。
Trueの場合、Djangoは空の値をNULLとしてデータベースに保存します。 デフォルトはFalseです。
CharField や TextField などの文字列ベースのフィールドで null を使用することは避けてください。 文字列ベースのフィールドにnull=Trueがある場合、それは「データなし」の2つの可能な値があることを意味します：NULLと空の文字列。 ほとんどの場合、「データなし」に2つの可能な値を設定することは冗長です。 Djangoの規則では、NULLではなく、空の文字列を使用します。 1つの例外は、 CharField にunique=Trueとblank=Trueの両方が設定されている場合です。 この状況では、空白の値で複数のオブジェクトを保存するときに一意の制約違反を回避するために、null=Trueが必要です。
null パラメータはデータベースストレージにのみ影響するため、文字列ベースのフィールドと非文字列ベースのフィールドの両方で、フォームに空の値を許可する場合は、blank=Trueも設定する必要があります（ 空白を参照）。
ノート
Oracleデータベースバックエンドを使用する場合、値NULLは、この属性に関係なく、空の文字列を示すために格納されます。
Trueの場合、フィールドは空白にすることができます。 デフォルトはFalseです。
これは null とは異なることに注意してください。 null は純粋にデータベース関連ですが、 blank は検証関連です。 フィールドにblank=Trueがある場合、フォームの検証では空の値を入力できます。 フィールドにblank=Falseがある場合、そのフィールドは必須です。
正確に2つのアイテムの反復可能オブジェクトで構成されるシーケンス（例： [(A, B), (A, B) ...]）このフィールドの選択肢として使用します。 選択肢が指定されている場合、それらはモデル検証によって適用され、デフォルトのフォームウィジェットは、標準のテキストフィールドではなく、これらの選択肢を含む選択ボックスになります。
各タプルの最初の要素はモデルに設定される実際の値であり、2番目の要素は人間が読める名前です。 例えば：
YEAR_IN_SCHOOL_CHOICES = [
('FR', 'Freshman'),
('SO', 'Sophomore'),
('JR', 'Junior'),
('SR', 'Senior'),
]一般に、モデルクラス内で選択肢を定義し、値ごとに適切な名前の定数を定義するのが最善です。
from django.db import models
class Student(models.Model):
FRESHMAN = 'FR'
SOPHOMORE = 'SO'
JUNIOR = 'JR'
SENIOR = 'SR'
YEAR_IN_SCHOOL_CHOICES = [
(FRESHMAN, 'Freshman'),
(SOPHOMORE, 'Sophomore'),
(JUNIOR, 'Junior'),
(SENIOR, 'Senior'),
]
year_in_school = models.CharField(
max_length=2,
choices=YEAR_IN_SCHOOL_CHOICES,
default=FRESHMAN,
)
def is_upperclass(self):
return self.year_in_school in (self.JUNIOR, self.SENIOR)モデルクラスの外部で選択肢リストを定義して参照することもできますが、モデルクラス内の各選択肢の選択肢と名前を定義すると、そのすべての情報がそれを使用するクラスに保持され、選択肢を簡単に参照できるようになります（たとえば、Student.SOPHOMOREは、Studentモデルがインポートされている場所であればどこでも機能します）。
利用可能な選択肢を、組織的な目的で使用できる名前付きグループに収集することもできます。
MEDIA_CHOICES = [
('Audio', (
('vinyl', 'Vinyl'),
('cd', 'CD'),
)
),
('Video', (
('vhs', 'VHS Tape'),
('dvd', 'DVD'),
)
),
('unknown', 'Unknown'),
]各タプルの最初の要素は、グループに適用する名前です。 2番目の要素は、2タプルの反復可能であり、各2タプルには、オプションの値と人間が読める形式の名前が含まれています。 グループ化されたオプションは、単一のリスト内でグループ化されていないオプションと組み合わせることができます（この例の不明オプションなど）。
choices が設定されているモデルフィールドごとに、Djangoはフィールドの現在の値の人間が読める名前を取得するメソッドを追加します。 データベースAPIドキュメントの get_FOO_display（）を参照してください。
選択肢は任意のシーケンスオブジェクトである可能性があることに注意してください。必ずしもリストやタプルである必要はありません。 これにより、選択肢を動的に構築できます。 ただし、 choices を動的にハッキングしていることに気付いた場合は、 ForeignKey を使用して適切なデータベーステーブルを使用することをお勧めします。 choices は、変更がほとんどない静的データを対象としています。
ノート
choicesの順序が変更されるたびに、新しい移行が作成されます。
blank = False が default とともにフィールドに設定されていない限り、"---------"を含むラベルが選択ボックスでレンダリングされます。 この動作をオーバーライドするには、Noneを含むタプルをchoicesに追加します。 例えば (None, 'Your String For Display')。 または、Noneの代わりに空の文字列を使用することもできます。これは、 CharField のように意味があります。
このフィールドに使用するデータベース列の名前。 これが指定されていない場合、Djangoはフィールドの名前を使用します。
データベースの列名がSQLの予約語である場合、またはPython変数名で許可されていない文字（特にハイフン）が含まれている場合は問題ありません。 Djangoは、舞台裏で列とテーブルの名前を引用しています。
Trueの場合、このフィールドのデータベースインデックスが作成されます。
このフィールドにインデックスが付けられている場合に、このフィールドのインデックスに使用するデータベーステーブルスペースの名前。 デフォルトは、プロジェクトの：setting： `DEFAULT_INDEX_TABLESPACE` 設定（設定されている場合）、またはモデルの db_tablespace （存在する場合）です。 バックエンドがインデックスのテーブルスペースをサポートしていない場合、このオプションは無視されます。
フィールドのデフォルト値。 これは、値または呼び出し可能オブジェクトにすることができます。 呼び出し可能であれば、新しいオブジェクトが作成されるたびに呼び出されます。
デフォルトは可変オブジェクト（モデルインスタンス、list、setなど）にすることはできません。そのオブジェクトの同じインスタンスへの参照がすべてのデフォルト値として使用されるためです。新しいモデルインスタンス。 代わりに、必要なデフォルトを呼び出し可能ファイルでラップします。 たとえば、 JSONField にデフォルトのdictを指定する場合は、次の関数を使用します。
def contact_default():
return {"email": "to1@example.com"}
contact_info = JSONField("ContactInfo", default=contact_default)lambdaは、移行によってシリアル化できないため、defaultのようなフィールドオプションには使用できません。 その他の注意事項については、そのドキュメントを参照してください。
モデルインスタンスにマップする ForeignKey のようなフィールドの場合、デフォルトは、モデルインスタンスではなく、参照するフィールドの値（ to_field が設定されていない場合はpk）である必要があります。
デフォルト値は、新しいモデルインスタンスが作成され、フィールドに値が指定されていない場合に使用されます。 フィールドが主キーの場合、フィールドがNoneに設定されている場合もデフォルトが使用されます。
Falseの場合、フィールドは管理者またはその他の ModelForm に表示されません。 モデルの検証の間もスキップされます。 デフォルトはTrueです。
error_messages引数を使用すると、フィールドで発生するデフォルトのメッセージを上書きできます。 オーバーライドするエラーメッセージに一致するキーを使用して辞書を渡します。
エラーメッセージキーには、null、blank、invalid、invalid_choice、unique、unique_for_dateがあります。 以下のフィールドタイプセクションでは、フィールドごとに追加のエラーメッセージキーが指定されています。
これらのエラーメッセージは、多くの場合、フォームに伝播されません。 モデルのerror_messages に関する考慮事項を参照してください。
フォームウィジェットで表示される追加の「ヘルプ」テキスト。 フィールドがフォームで使用されていない場合でも、ドキュメントに役立ちます。
この値は、自動生成された形式ではではなく HTMLエスケープされることに注意してください。 これにより、必要に応じて help_text にHTMLを含めることができます。 例えば：
help_text="Please use the following format: <em>YYYY-MM-DD</em>."または、プレーンテキストと django.utils.html.escape（）を使用して、HTMLの特殊文字をエスケープすることもできます。 クロスサイトスクリプティング攻撃を回避するために、信頼できないユーザーから送信される可能性のあるヘルプテキストを必ずエスケープしてください。
Trueの場合、このフィールドはモデルの主キーです。
モデルのどのフィールドにもprimary_key=Trueを指定しない場合、Djangoは主キーを保持するために AutoField を自動的に追加するため、primary_key=Trueを設定する必要はありません。 ]デフォルトの主キーの動作をオーバーライドする場合を除き、任意のフィールドで。 詳細については、自動主キーフィールドを参照してください。
primary_key=Trueは、 null = False および unique = True を意味します。 オブジェクトで許可される主キーは1つだけです。
主キーフィールドは読み取り専用です。 既存のオブジェクトの主キーの値を変更して保存すると、古いオブジェクトと一緒に新しいオブジェクトが作成されます。
Trueの場合、このフィールドはテーブル全体で一意である必要があります。
これは、データベースレベルおよびモデル検証によって実施されます。 unique フィールドに重複する値を持つモデルを保存しようとすると、モデルの save（）メソッドによって django.db.IntegrityError が発生します。 。
このオプションは、 ManyToManyField と OneToOneField を除くすべてのフィールドタイプで有効です。
uniqueがTrueの場合、uniqueはインデックスの作成を意味するため、 db_index を指定する必要はありません。
これを DateField または DateTimeField の名前に設定して、このフィールドが日付フィールドの値に対して一意であることを要求します。
たとえば、unique_for_date="pub_date"を持つフィールドtitleがある場合、Djangoは同じtitleとpub_dateを持つ2つのレコードの入力を許可しません。 。
これを DateTimeField を指すように設定すると、フィールドの日付部分のみが考慮されることに注意してください。 また、：setting： `USE_TZ` がTrueの場合、オブジェクトが保存された時点で現在のタイムゾーンでチェックが実行されます。
これは、モデルの検証中に Model.validate_unique（）によって適用されますが、データベースレベルでは適用されません。 unique_for_date 制約に、 ModelForm の一部ではないフィールドが含まれる場合（たとえば、フィールドの1つがexcludeにリストされている場合、または editable = False ）、 Model.validate_unique（）は、その特定の制約の検証をスキップします。
フィールドの人間が読める名前。 詳細な名前が指定されていない場合、Djangoはフィールドの属性名を使用して自動的に作成し、アンダースコアをスペースに変換します。 詳細フィールド名を参照してください。
このフィールドに対して実行するバリデーターのリスト。 詳細については、バリデーターのドキュメントを参照してください。
Fieldは、ルックアップ登録API を実装します。 APIを使用して、フィールドクラスで使用できるルックアップ、およびフィールドからルックアップをフェッチする方法をカスタマイズできます。
使用可能なIDに従って自動的にインクリメントする IntegerField 。 通常、これを直接使用する必要はありません。 特に指定しない場合、主キーフィールドはモデルに自動的に追加されます。 自動主キーフィールドを参照してください。
1から9223372036854775807までの数値に適合することが保証されていることを除いて、 AutoField によく似た64ビット整数。
[X101X] から9223372036854775807までの数値に適合することが保証されていることを除いて、 IntegerField によく似た64ビット整数。 このフィールドのデフォルトのフォームウィジェットは TextInput です。
生のバイナリデータを格納するフィールド。 bytes、bytearray、またはmemoryviewを割り当てることができます。
デフォルトでは、BinaryFieldは編集可能をFalseに設定します。この場合、 ModelForm に含めることはできません。
バージョン2.1で変更：古いバージョンでは、editableをTrueに設定できません。
BinaryFieldには、オプションの引数が1つ追加されています。
虐待BinaryField
データベースにファイルを保存することを考えるかもしれませんが、99 % o fの場合は設計が悪いと考えてください。 このフィールドは、適切な静的ファイル処理の代わりにではありません。
真/偽のフィールド。
このフィールドのデフォルトのフォームウィジェットは CheckboxInput 、または null = True の場合は NullBooleanSelect です。
Field.default が定義されていない場合、BooleanFieldのデフォルト値はNoneです。
バージョン2.1で変更：古いバージョンでは、このフィールドはnull=Trueを許可しないため、代わりに NullBooleanField を使用する必要があります。 後者の使用は、Djangoの将来のバージョンで非推奨になる可能性があるため、現在は推奨されていません。
古いバージョンでは、このフィールドには暗黙的に blank = True があります。 blank=Trueを設定すると、以前の動作に戻すことができます。
小さいサイズから大きいサイズの文字列用の文字列フィールド。
大量のテキストの場合は、 TextField を使用してください。
このフィールドのデフォルトのフォームウィジェットは TextInput です。
CharField には、追加の必須引数が1つあります。
ノート
複数のデータベースバックエンドに移植可能でなければならないアプリケーションを作成している場合、一部のバックエンドではmax_lengthに制限があることに注意する必要があります。 詳細については、データベースバックエンドノートを参照してください。
Pythonではdatetime.dateインスタンスで表される日付。 いくつかの追加のオプションの引数があります。
オブジェクトが保存されるたびに、フィールドが自動的に[今すぐ]に設定されます。 「最終変更」タイムスタンプに役立ちます。 現在の日付は常にが使用されていることに注意してください。 オーバーライドできるのはデフォルト値だけではありません。
このフィールドは、 Model.save（）を呼び出したときにのみ自動的に更新されます。 QuerySet.update（）などの他の方法で他のフィールドを更新する場合、フィールドは更新されませんが、そのような更新でフィールドのカスタム値を指定することはできます。
auto_now_add=Trueの代わりに次のように設定します。default=date.today-datetime.date.today()からdefault=timezone.now- django.utils.timezone.now（）からこのフィールドのデフォルトのフォームウィジェットは TextInput です。 管理者は、JavaScriptカレンダーと、「今日」のショートカットを追加します。 追加のinvalid_dateエラーメッセージキーが含まれています。
オプションauto_now_add、auto_now、およびdefaultは相互に排他的です。 これらのオプションを任意に組み合わせると、エラーが発生します。
ノート
現在実装されているように、auto_nowまたはauto_now_addをTrueに設定すると、フィールドにeditable=Falseおよびblank=Trueが設定されます。
ノート
auto_nowおよびauto_now_addオプションは、作成時または更新時に常にデフォルトのタイムゾーンの日付を使用します。 別のものが必要な場合は、auto_nowまたはauto_now_addを使用する代わりに、独自の呼び出し可能なデフォルトを使用するか、save()をオーバーライドすることを検討してください。 または、DateFieldの代わりにDateTimeFieldを使用して、表示時間に日時から日付への変換を処理する方法を決定します。
Pythonではdatetime.datetimeインスタンスで表される日付と時刻。 DateField と同じ追加の引数を取ります。
このフィールドのデフォルトのフォームウィジェットは、単一の TextInput です。 管理者は、JavaScriptショートカットを備えた2つの別々の TextInput ウィジェットを使用します。
PythonではDecimalインスタンスで表される固定精度の10進数。 DecimalValidator を使用して入力を検証します。
2つの必須引数があります。
decimal_places以上である必要があることに注意してください。たとえば、小数点以下2桁の解像度で999までの数値を格納するには、次を使用します。
models.DecimalField(..., max_digits=5, decimal_places=2)また、小数点以下10桁の解像度で、最大約10億の数値を格納するには：
models.DecimalField(..., max_digits=19, decimal_places=10)このフィールドのデフォルトのフォームウィジェットは、 localize がFalseの場合は NumberInput 、それ以外の場合は TextInput です。
ノート
の違いの詳細については FloatField と DecimalField クラス、ご覧ください FloatField対。 DecimalField 。 また、10進数フィールドの SQLiteの制限にも注意する必要があります。
期間を保存するためのフィールド-Pythonでtimedeltaによってモデル化されています。 PostgreSQLで使用する場合、使用されるデータ型はintervalであり、Oracleではデータ型はINTERVAL DAY(9) TO SECOND(6)です。 それ以外の場合は、マイクロ秒のbigintが使用されます。
ノート
DurationFieldを使用した算術演算はほとんどの場合機能します。 ただし、PostgreSQL以外のすべてのデータベースでは、DurationFieldの値をDateTimeFieldインスタンスの算術演算と比較しても期待どおりに機能しません。
EmailValidator を使用して、値が有効な電子メールアドレスであることを確認する CharField 。
ファイルアップロードフィールド。
ノート
primary_key引数はサポートされておらず、使用するとエラーが発生します。
2つのオプションの引数があります。
この属性は、アップロードディレクトリとファイル名を設定する方法を提供し、2つの方法で設定できます。 どちらの場合も、値は Storage.save（）メソッドに渡されます。
文字列値を指定すると、strftime()形式が含まれる場合があります。これは、ファイルのアップロードの日付/時刻に置き換えられます（アップロードされたファイルが指定されたディレクトリをいっぱいにしないようにするため）。 例えば：
class MyModel(models.Model):
# file will be uploaded to MEDIA_ROOT/uploads
upload = models.FileField(upload_to='uploads/')
# or...
# file will be saved to MEDIA_ROOT/uploads/2015/01/30
upload = models.FileField(upload_to='uploads/%Y/%m/%d/')デフォルトの FileSystemStorage を使用している場合、文字列値が：setting： `MEDIA_ROOT` パスに追加され、アップロードされたファイルが保存されるローカルファイルシステム上の場所が形成されます。 別のストレージを使用している場合は、そのストレージのドキュメントをチェックして、upload_toの処理方法を確認してください。
upload_toは、関数などの呼び出し可能でもあります。 これは、ファイル名を含むアップロードパスを取得するために呼び出されます。 この呼び出し可能オブジェクトは、2つの引数を受け入れ、ストレージシステムに渡されるUnixスタイルのパス（スラッシュ付き）を返す必要があります。 2つの引数は次のとおりです。
引数 |
説明 |
|---|---|
|
ほとんどの場合、このオブジェクトはまだデータベースに保存されていないため、デフォルトの |
|
ファイルに最初に付けられたファイル名。 これは、最終的な宛先パスを決定するときに考慮される場合と考慮されない場合があります。 |
例えば：
def user_directory_path(instance, filename):
# file will be uploaded to MEDIA_ROOT/user_<id>/<filename>
return 'user_{0}/{1}'.format(instance.user.id, filename)
class MyModel(models.Model):
upload = models.FileField(upload_to=user_directory_path)このフィールドのデフォルトのフォームウィジェットは ClearableFileInput です。
モデルで FileField または ImageField （以下を参照）を使用するには、いくつかの手順を実行します。
mug_shotの場合、テンプレート:Object.mug shot.urlを使用してテンプレート内の画像への絶対パスを取得できます。たとえば、：setting： `MEDIA_ROOT` が'/home/media'に設定され、 upload_to が'photos/%Y/%m/%d'に設定されているとします。 upload_to の'%Y/%m/%d'部分は、strftime()フォーマットです。 '%Y'は4桁の年、'%m'は2桁の月、'%d'は2桁の日です。 1月にファイルをアップロードした場合。 2007年15日、ディレクトリ/home/media/photos/2007/01/15に保存されます。
アップロードされたファイルのディスク上のファイル名またはファイルのサイズを取得する場合は、それぞれ name 属性と size 属性を使用できます。 使用可能な属性とメソッドの詳細については、ファイルクラスリファレンスおよびファイルの管理トピックガイドを参照してください。
ノート
ファイルはデータベースへのモデルの保存の一部として保存されるため、ディスクで使用される実際のファイル名は、モデルが保存されるまで信頼できません。
アップロードされたファイルの相対URLは、 url 属性を使用して取得できます。 内部的には、これは基礎となる Storage クラスの url（）メソッドを呼び出します。
アップロードされたファイルを処理するときは常に、セキュリティホールを回避するために、アップロードする場所とファイルの種類に細心の注意を払う必要があることに注意してください。 アップロードされたすべてのファイルを検証して、ファイルが思いどおりのものであることを確認します。 たとえば、誰かが検証なしでWebサーバーのドキュメントルート内のディレクトリにファイルをやみくもにアップロードするようにした場合、誰かがCGIまたはPHPスクリプトをアップロードし、サイトのURLにアクセスしてそのスクリプトを実行する可能性があります。 それを許可しないでください。
また、アップロードされたHTMLファイルでさえ、（サーバーではなく）ブラウザーで実行できるため、XSSまたはCSRF攻撃と同等のセキュリティ脅威をもたらす可能性があることにも注意してください。
FileField インスタンスは、デフォルトの最大長100文字のvarchar列としてデータベースに作成されます。 他のフィールドと同様に、 max_length 引数を使用して最大長を変更できます。
モデルの FileField にアクセスすると、基になるファイルにアクセスするためのプロキシとして FieldFile のインスタンスが提供されます。
FieldFile のAPIは、 File のAPIを反映していますが、重要な違いが1つあります。クラスによってラップされるオブジェクトは、必ずしもPythonの組み込みファイルオブジェクトのラッパーではありません。[X188X ]代わりに、 Storage.open（）メソッドの結果のラッパーであり、 File オブジェクトであるか、カスタムストレージの[X367Xの実装である可能性があります。 ]ファイル API。
read()やwrite()などの File から継承されたAPIに加えて、 FieldFile には、基になるファイルとの対話に使用できるいくつかのメソッドが含まれています：
関連する FileField の Storage のルートからの相対パスを含むファイルの名前。
基になる Storage.size（）メソッドの結果。
基になる Storage クラスの url（）メソッドを呼び出して、ファイルの相対URLにアクセスするための読み取り専用プロパティ。
指定されたmodeで、このインスタンスに関連付けられているファイルを開くか、再度開きます。 標準のPython open()メソッドとは異なり、ファイル記述子を返しません。
基になるファイルは、アクセス時に暗黙的に開かれるため、基になるファイルへのポインタをリセットするか、modeを変更する場合を除いて、このメソッドを呼び出す必要がない場合があります。
標準のPython file.close()メソッドのように動作し、このインスタンスに関連付けられているファイルを閉じます。
このメソッドは、ファイル名とファイルの内容を受け取り、それらをフィールドのストレージクラスに渡し、保存されたファイルをモデルフィールドに関連付けます。 ファイルデータをモデル上の FileField インスタンスに手動で関連付ける場合は、save()メソッドを使用してそのファイルデータを永続化します。
ファイルの名前であるnameと、ファイルの内容を含むオブジェクトであるcontentの2つの必須引数を取ります。 オプションのsave引数は、このフィールドに関連付けられたファイルが変更された後にモデルインスタンスを保存するかどうかを制御します。 デフォルトはTrueです。
content引数は、Pythonの組み込みファイルオブジェクトではなく、 django.core.files.File のインスタンスである必要があることに注意してください。 次のように、既存のPythonファイルオブジェクトから File を作成できます。
from django.core.files import File
# Open an existing file using Python's built-in open()
f = open('/path/to/hello.world')
myfile = File(f)または、次のようにPython文字列から作成できます。
from django.core.files.base import ContentFile
myfile = ContentFile("hello world")詳細については、ファイルの管理を参照してください。
このインスタンスに関連付けられているファイルを削除し、フィールドのすべての属性をクリアします。 注：このメソッドは、delete()が呼び出されたときにファイルが開いている場合、ファイルを閉じます。
オプションのsave引数は、このフィールドに関連付けられたファイルが削除された後にモデルインスタンスを保存するかどうかを制御します。 デフォルトはTrueです。
モデルが削除されても、関連ファイルは削除されないことに注意してください。 孤立したファイルをクリーンアップする必要がある場合は、自分で処理する必要があります（たとえば、手動で実行したり、たとえばを介して定期的に実行するようにスケジュールしたりできるカスタム管理コマンドを使用して） cron）。
CharField の選択肢は、ファイルシステム上の特定のディレクトリ内のファイル名に限定されています。 3つの特別な引数があり、そのうちの最初の引数は必須です。
"/home/images"。"foo.*\.txt$"。これはfoo23.txtというファイルと一致しますが、bar.txtまたはfoo23.pngとは一致しません。TrueまたはFalseのいずれか。 デフォルトはFalseです。 パスのすべてのサブディレクトリを含めるかどうかを指定しますTrueまたはFalseのいずれか。 デフォルトはTrueです。 指定した場所にあるファイルを含めるかどうかを指定します。 これまたは allow_folders はTrueである必要があります。TrueまたはFalseのいずれか。 デフォルトはFalseです。 指定した場所のフォルダーを含めるかどうかを指定します。 これまたは allow_files はTrueである必要があります。もちろん、これらの引数は一緒に使用できます。
潜在的な落とし穴の1つは、 match がフルパスではなく、ベースファイル名に適用されることです。 したがって、この例：
FilePathField(path="/home/images", match="foo.*", recursive=True)… match はベースファイル名（foo.pngおよびbar.png）に適用されるため、/home/images/foo.pngと一致しますが、/home/images/foo/bar.pngとは一致しません。
FilePathField インスタンスは、デフォルトの最大長100文字のvarchar列としてデータベースに作成されます。 他のフィールドと同様に、 max_length 引数を使用して最大長を変更できます。
Pythonでfloatインスタンスによって表される浮動小数点数。
このフィールドのデフォルトのフォームウィジェットは、 localize がFalseの場合は NumberInput 、それ以外の場合は TextInput です。
FloatField対。 DecimalField
FloatField クラスが DecimalField クラスと混同されることがあります。 どちらも実数を表しますが、それらの数は異なります。 FloatFieldはPythonのfloatタイプを内部的に使用し、DecimalFieldはPythonのDecimalタイプを使用します。 2つの違いについては、decimalモジュールに関するPythonのドキュメントを参照してください。
FileField からすべての属性とメソッドを継承しますが、アップロードされたオブジェクトが有効な画像であることも検証します。
FileField で使用できる特別な属性に加えて、 ImageField にはheightおよびwidth属性もあります。
これらの属性のクエリを容易にするために、 ImageField には2つの追加のオプション引数があります。
枕ライブラリが必要です。
ImageField インスタンスは、デフォルトの最大長100文字のvarchar列としてデータベースに作成されます。 他のフィールドと同様に、 max_length 引数を使用して最大長を変更できます。
このフィールドのデフォルトのフォームウィジェットは ClearableFileInput です。
整数。 -2147483648から2147483647までの値は、Djangoでサポートされているすべてのデータベースで安全です。
MinValueValidator および MaxValueValidator を使用して、デフォルトのデータベースがサポートする値に基づいて入力を検証します。
このフィールドのデフォルトのフォームウィジェットは、 localize がFalseの場合は NumberInput 、それ以外の場合は TextInput です。
文字列形式のIPv4またはIPv6アドレス（例： 192.0.2.30または2a02:42fe::4）。 このフィールドのデフォルトのフォームウィジェットは TextInput です。
IPv6アドレスの正規化は、 RFC 4291＃section-2.2 セクション2.2に従います。これには、::ffff:192.0.2.0などのセクションの段落3で提案されているIPv4形式の使用も含まれます。 たとえば、2001:0::0:01は2001::1に正規化され、::ffff:0a0a:0a0aは::ffff:10.10.10.10に正規化されます。 すべての文字は小文字に変換されます。
'both'（デフォルト）、'IPv4'、または'IPv6'です。 マッチングでは大文字と小文字は区別されません。::ffff:192.0.2.1のようなIPv4マップアドレスを解凍します。 このオプションを有効にすると、そのアドレスは192.0.2.1に解凍されます。 デフォルトは無効です。 protocolが'both'に設定されている場合にのみ使用できます。空白値を許可する場合、空白値はnullとして格納されるため、null値を許可する必要があります。
BooleanField とnull=Trueのように。 Djangoの将来のバージョンで非推奨になる可能性があるため、このフィールドの代わりにこれを使用してください。
IntegerField と同様ですが、正またはゼロ（0）である必要があります。 0から2147483647までの値は、Djangoでサポートされているすべてのデータベースで安全です。 値0は、下位互換性の理由から受け入れられます。
PositiveIntegerField と同様ですが、特定の（データベースに依存する）ポイントの下の値のみを許可します。 0から32767までの値は、Djangoでサポートされているすべてのデータベースで安全です。
Slug は新聞用語です。 スラッグは何かの短いラベルであり、文字、数字、アンダースコア、またはハイフンのみが含まれます。 それらは一般的にURLで使用されます。
CharFieldと同様に、 max_length を指定できます（そのセクションのデータベースの移植性と max_length に関する注記も読んでください）。 max_length が指定されていない場合、Djangoはデフォルトの長さ50を使用します。
Field.db_index をTrueに設定することを意味します。
他の値の値に基づいてSlugFieldを自動的に事前入力すると便利なことがよくあります。 prepopulated_fields を使用して、管理者でこれを自動的に行うことができます。
検証には validate_slug または validate_unicode_slug を使用します。
Trueの場合、フィールドはASCII文字に加えてUnicode文字を受け入れます。 デフォルトはFalseです。
IntegerField と同様ですが、特定の（データベースに依存する）ポイントの下の値のみを許可します。 -32768から32767までの値は、Djangoでサポートされているすべてのデータベースで安全です。
大きなテキストフィールド。 このフィールドのデフォルトのフォームウィジェットは Textarea です。
max_length属性を指定すると、自動生成されたフォームフィールドの Textarea ウィジェットに反映されます。 ただし、モデルまたはデータベースレベルでは適用されません。 そのためには CharField を使用してください。
Pythonではdatetime.timeインスタンスで表される時間。 DateField と同じ自動入力オプションを受け入れます。
このフィールドのデフォルトのフォームウィジェットは TextInput です。 管理者はいくつかのJavaScriptショートカットを追加します。
URLValidator によって検証されたURLの CharField 。
このフィールドのデフォルトのフォームウィジェットは TextInput です。
すべての CharField サブクラスと同様に、 URLField はオプションの max_length 引数を取ります。 max_length を指定しない場合、デフォルトの200が使用されます。
普遍的に一意の識別子を格納するためのフィールド。 PythonのUUIDクラスを使用します。 PostgreSQLで使用する場合、これはuuidデータ型に格納されます。それ以外の場合は、char(32)に格納されます。
ユニバーサル一意識別子は、 primary_key の AutoField の優れた代替手段です。 データベースはUUIDを生成しないため、 default を使用することをお勧めします。
import uuid
from django.db import models
class MyUUIDModel(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
# other fieldsUUIDのインスタンスではなく、呼び出し可能オブジェクト（括弧を省略）がdefaultに渡されることに注意してください。
PostgreSQLでのルックアップ
：lookup： `iexact` 、：lookup：` contains` 、：lookup： `icontains` 、：lookup：` startswith` [を使用X116X]、：lookup： `istartswith` 、：lookup：` endswith` 、または：lookup： `iendswith` PostgreSQLでのルックアップは機能しませんPostgreSQLはハイフン付きのuuidデータ型に値を格納するため、ハイフンなしの値。
Djangoは、関係を表す一連のフィールドも定義します。
多対1の関係。 モデルが関連するクラスと on_delete オプションの2つの位置引数が必要です。
再帰的な関係（それ自体と多対1の関係を持つオブジェクト）を作成するには、models.ForeignKey('self', on_delete=models.CASCADE)を使用します。
まだ定義されていないモデルでリレーションシップを作成する必要がある場合は、モデルオブジェクト自体ではなく、モデルの名前を使用できます。
from django.db import models
class Car(models.Model):
manufacturer = models.ForeignKey(
'Manufacturer',
on_delete=models.CASCADE,
)
# ...
class Manufacturer(models.Model):
# ...
pass抽象モデルでこのように定義された関係は、モデルが具象モデルとしてサブクラス化され、抽象モデルのapp_labelに関連していない場合に解決されます。
products / models.py
from django.db import models
class AbstractCar(models.Model):
manufacturer = models.ForeignKey('Manufacturer', on_delete=models.CASCADE)
class Meta:
abstract = Trueproduction / models.py
from django.db import models
from products.models import AbstractCar
class Manufacturer(models.Model):
pass
class Car(AbstractCar):
pass
# Car.manufacturer will point to `production.Manufacturer` here.別のアプリケーションで定義されたモデルを参照するには、完全なアプリケーションラベルを使用してモデルを明示的に指定できます。 たとえば、上記のManufacturerモデルがproductionという別のアプリケーションで定義されている場合は、次のものを使用する必要があります。
class Car(models.Model):
manufacturer = models.ForeignKey(
'production.Manufacturer',
on_delete=models.CASCADE,
)レイジーリレーションシップと呼ばれるこの種の参照は、2つのアプリケーション間の循環インポートの依存関係を解決するときに役立ちます。
データベースインデックスはForeignKeyに自動的に作成されます。 db_index をFalseに設定すると、これを無効にできます。 結合ではなく一貫性のために外部キーを作成する場合、または部分列インデックスや複数列インデックスなどの代替インデックスを作成する場合は、インデックスのオーバーヘッドを回避することをお勧めします。
舞台裏では、Djangoはフィールド名に"_id"を追加して、データベースの列名を作成します。 上記の例では、Carモデルのデータベーステーブルにmanufacturer_id列があります。 （ db_column を指定することで、これを明示的に変更できます）ただし、カスタムSQLを記述しない限り、コードでデータベースの列名を処理する必要はありません。 モデルオブジェクトのフィールド名は常に処理します。
ForeignKey は、関係がどのように機能するかの詳細を定義する他の引数を受け入れます。
ForeignKey によって参照されるオブジェクトが削除されると、Djangoは on_delete 引数によって指定されたSQL制約の動作をエミュレートします。 たとえば、null許容の ForeignKey があり、参照されているオブジェクトが削除されたときにnullに設定する場合は次のようになります。
user = models.ForeignKey(
User,
models.SET_NULL,
blank=True,
null=True,
)on_deleteは、データベースにSQL制約を作成しません。 データベースレベルのカスケードオプションのサポート ：ticket： `後で実装される可能性があります<21961>` 。
on_delete の可能な値は、 django.db.models にあります。
カスケード削除。 Djangoは、SQL制約ON DELETE CASCADEの動作をエミュレートし、ForeignKeyを含むオブジェクトも削除します。
Model.delete（）は関連モデルでは呼び出されませんが、 pre_delete および post_delete シグナルはすべての削除されたオブジェクトに対して送信されます。
django.db.IntegrityError のサブクラスである ProtectedError を発生させて、参照されているオブジェクトが削除されないようにします。
ForeignKey をnullに設定します。 これは、 null がTrueの場合にのみ可能です。
ForeignKey をデフォルト値に設定します。 ForeignKey のデフォルトを設定する必要があります。
ForeignKey を SET（）に渡された値に設定するか、callableが渡された場合は、それを呼び出した結果に設定します。 ほとんどの場合、models.pyのインポート時にクエリが実行されないようにするには、callableを渡す必要があります。
from django.conf import settings
from django.contrib.auth import get_user_model
from django.db import models
def get_sentinel_user():
return get_user_model().objects.get_or_create(username='deleted')[0]
class MyModel(models.Model):
user = models.ForeignKey(
settings.AUTH_USER_MODEL,
on_delete=models.SET(get_sentinel_user),
)何もするな。 データベースバックエンドが参照整合性を適用する場合、SQL ON DELETE制約をデータベースフィールドに手動で追加しない限り、 IntegrityError が発生します。
このフィールドがModelFormまたはadminを使用してレンダリングされるときに、このフィールドで使用可能な選択肢に制限を設定します（デフォルトでは、クエリセット内のすべてのオブジェクトを選択できます）。 ディクショナリ、 Q オブジェクト、またはディクショナリまたは Q オブジェクトを返す呼び出し可能オブジェクトのいずれかを使用できます。
例えば：
staff_member = models.ForeignKey(
User,
on_delete=models.CASCADE,
limit_choices_to={'is_staff': True},
)ModelFormの対応するフィールドに、is_staff=Trueを持つUsersのみがリストされます。 これはDjango管理者に役立つかもしれません。
呼び出し可能なフォームは、たとえば、Python datetimeモジュールと組み合わせて使用して、日付範囲による選択を制限する場合に役立ちます。 例えば：
def limit_pub_date_choices():
return {'pub_date__lte': datetime.date.utcnow()}
limit_choices_to = limit_pub_date_choiceslimit_choices_toが Qオブジェクトであるか、複雑なクエリに役立つを返す場合、フィールドが管理者で使用可能な選択肢にのみ影響します。モデルのModelAdminの raw_id_fields にリストされていません。
ノート
limit_choices_toに呼び出し可能オブジェクトが使用されている場合、新しいフォームがインスタンス化されるたびに呼び出されます。 また、管理コマンドや管理者などによってモデルが検証されたときに呼び出されることもあります。 管理者は、さまざまなエッジケースでフォーム入力を複数回検証するクエリセットを作成するため、callableが複数回呼び出される可能性があります。
関連オブジェクトからこのオブジェクトへのリレーションに使用する名前。 これは、 related_query_name （ターゲットモデルからの逆フィルター名に使用する名前）のデフォルト値でもあります。 完全な説明と例については、関連オブジェクトのドキュメントを参照してください。 抽象モデルでリレーションを定義するときは、この値を設定する必要があることに注意してください。 そうすると、いくつかの特別な構文が利用可能になります。
Djangoで後方関係を作成したくない場合は、related_nameを'+'に設定するか、'+'で終了します。 たとえば、これにより、Userモデルがこのモデルと後方関係を持たないことが保証されます。
user = models.ForeignKey(
User,
on_delete=models.CASCADE,
related_name='+',
)ターゲットモデルからの逆フィルター名に使用する名前。 デフォルトでは、 related_name または default_related_name の値に設定されています。設定されていない場合、デフォルトでモデルの名前になります。
# Declare the ForeignKey with related_query_name
class Tag(models.Model):
article = models.ForeignKey(
Article,
on_delete=models.CASCADE,
related_name="tags",
related_query_name="tag",
)
name = models.CharField(max_length=255)
# That's now the name of the reverse filter
Article.objects.filter(tag__name="important")related_name と同様に、related_query_nameは、いくつかの特別な構文を介してアプリのラベルとクラスの補間をサポートします。
unique=Trueが必要です。この外部キーの制約をデータベースに作成するかどうかを制御します。 デフォルトはTrueであり、これはほぼ確実に必要なものです。 これをFalseに設定すると、データの整合性が非常に悪くなる可能性があります。 そうは言っても、これを実行したいシナリオがいくつかあります。
無効なレガシーデータがあります。
データベースをシャーディングしています。
これがFalseに設定されている場合、存在しない関連オブジェクトにアクセスすると、DoesNotExist例外が発生します。
この ForeignKey がスワップ可能なモデルを指している場合、移行フレームワークの反応を制御します。 True（デフォルト）の場合、 ForeignKey がsettings.AUTH_USER_MODEL（または別の交換可能なモデル設定）の現在の値と一致するモデルを指している場合、関係は次のようになります。モデルを直接参照するのではなく、設定への参照を使用して移行に保存されます。
モデルが常にスワップインされたモデルを指すようにする必要がある場合、たとえば、カスタムユーザーモデル用に特別に設計されたプロファイルモデルである場合にのみ、これをFalseにオーバーライドする必要があります。
Falseに設定しても、スワップアウトされた場合でもスワップ可能なモデルを参照できるわけではありません。Falseは、このForeignKeyで行われた移行が、指定した正確なモデルを常に参照することを意味します（したがって、たとえば、サポートされていないユーザーモデルでユーザーが実行しようとすると、失敗します。
疑わしい場合は、デフォルトのTrueのままにしてください。
多対多の関係。 位置引数が必要です。モデルが関連するクラスです。これは、再帰およびレイジー関係を含め、外部キーの場合とまったく同じように機能します。
関連オブジェクトは、フィールドの RelatedManager を使用して追加、削除、または作成できます。
舞台裏では、Djangoは多対多の関係を表す中間結合テーブルを作成します。 デフォルトでは、このテーブル名は、多対多フィールドの名前とそれを含むモデルのテーブルの名前を使用して生成されます。 一部のデータベースは特定の長さを超えるテーブル名をサポートしていないため、これらのテーブル名は自動的に切り捨てられ、一意性ハッシュが使用されます。 author_books_9cdf。 db_table オプションを使用して、結合テーブルの名前を手動で指定できます。
ManyToManyField は、関係の機能を制御する追加の引数セット（すべてオプション）を受け入れます。
ForeignKey.limit_choices_to と同じです。
limit_choices_toは、からパラメーターを使用して指定されたカスタム中間テーブルを持つManyToManyFieldで使用された場合は効果がありません。
自分自身のManyToManyFieldsの定義でのみ使用されます。 次のモデルを検討してください。
from django.db import models
class Person(models.Model):
friends = models.ManyToManyField("self")Djangoがこのモデルを処理するとき、Djangoはそれ自体に ManyToManyField があることを識別し、その結果、Personクラスにperson_set属性を追加しません。 代わりに、 ManyToManyField は対称であると見なされます。つまり、私があなたの友人である場合、あなたは私の友人です。
selfとの多対多の関係で対称性を望まない場合は、対称をFalseに設定します。 これにより、Djangoは逆の関係の記述子を追加し、 ManyToManyField の関係を非対称にすることができます。
Djangoは、多対多の関係を管理するためのテーブルを自動的に生成します。 ただし、中間テーブルを手動で指定する場合は、からオプションを使用して、使用する中間テーブルを表すDjangoモデルを指定できます。
このオプションの最も一般的な使用法は、追加データを多対多の関係に関連付ける場合です。
明示的なthroughモデルを指定しない場合でも、関連付けを保持するために作成されたテーブルに直接アクセスするために使用できる暗黙的なthroughモデルクラスがあります。 モデルをリンクするための3つのフィールドがあります。
ソースモデルとターゲットモデルが異なる場合、次のフィールドが生成されます。
id：リレーションの主キー。
<containing_model>_id：ManyToManyFieldを宣言するモデルのid。
<other_model>_id：ManyToManyFieldが指すモデルのid。
ManyToManyFieldが同じモデルを指している場合、同じモデルを指している場合、次のフィールドが生成されます。
id：リレーションの主キー。
from_<model>_id：モデルを指すインスタンスのid（つまり、 ソースインスタンス）。
to_<model>_id：関係が指すインスタンスのid（つまり、 ターゲットモデルインスタンス）。
このクラスは、通常のモデルと同様に、特定のモデルインスタンスの関連レコードをクエリするために使用できます。
カスタム中間モデルが指定されている場合にのみ使用されます。 Djangoは通常、多対多の関係を自動的に確立するために、中間モデルのどのフィールドを使用するかを決定します。 ただし、次のモデルを検討してください。
from django.db import models
class Person(models.Model):
name = models.CharField(max_length=50)
class Group(models.Model):
name = models.CharField(max_length=128)
members = models.ManyToManyField(
Person,
through='Membership',
through_fields=('group', 'person'),
)
class Membership(models.Model):
group = models.ForeignKey(Group, on_delete=models.CASCADE)
person = models.ForeignKey(Person, on_delete=models.CASCADE)
inviter = models.ForeignKey(
Person,
on_delete=models.CASCADE,
related_name="membership_invites",
)
invite_reason = models.CharField(max_length=64)MembershipにはPersonへの 2つの外部キー（personとinviter）があり、関係があいまいになり、Djangoは認識できません。どちらを使用するか。 この場合、上記の例のように、through_fieldsを使用してDjangoが使用する外部キーを明示的に指定する必要があります。
through_fieldsは、2タプル('field1', 'field2')を受け入れます。ここで、field1は、 ManyToManyField が定義されているモデルの外部キーの名前です（groupこの場合）、およびfield2ターゲットモデルへの外部キーの名前（この場合はperson）。
多対多の関係に参加しているモデルのいずれか（または両方）に対する中間モデルに複数の外部キーがある場合は、必ずthrough_fieldsを指定する必要があります。 これは、中間モデルが使用され、モデルに3つ以上の外部キーがある場合、または2つのDjangoが使用する2つを明示的に指定する場合の再帰的関係にも当てはまります。
中間モデルを使用した再帰的関係は、常に非対称として定義されます。つまり、 symmetrical = False であるため、「ソース」と「ターゲット」の概念があります。 その場合、'field1'は関係の「ソース」として扱われ、'field2'は「ターゲット」として扱われます。
中間テーブルの外部キーの制約をデータベースに作成するかどうかを制御します。 デフォルトはTrueであり、これはほぼ確実に必要なものです。 これをFalseに設定すると、データの整合性が非常に悪くなる可能性があります。 そうは言っても、これを実行したいシナリオがいくつかあります。
無効なレガシーデータがあります。
データベースをシャーディングしています。
db_constraintとthroughの両方を渡すとエラーになります。
この ManyToManyField がスワップ可能なモデルを指している場合、移行フレームワークの反応を制御します。 True（デフォルト）の場合、 ManyToManyField がsettings.AUTH_USER_MODEL（または別の交換可能なモデル設定）の現在の値と一致するモデルを指している場合、関係は次のようになります。モデルを直接参照するのではなく、設定への参照を使用して移行に保存されます。
モデルが常にスワップインされたモデルを指すようにする必要がある場合、たとえば、カスタムユーザーモデル用に特別に設計されたプロファイルモデルである場合にのみ、これをFalseにオーバーライドする必要があります。
疑わしい場合は、デフォルトのTrueのままにしてください。
ManyToManyField はバリデーターをサポートしていません。
null は、データベースレベルでの関係を要求する方法がないため、効果がありません。
1対1の関係。 概念的には、これは unique = True の ForeignKey に似ていますが、リレーションの「逆」側は単一のオブジェクトを直接返します。
これは、何らかの方法で別のモデルを「拡張」するモデルの主キーとして最も役立ちます。 マルチテーブル継承は、たとえば、子モデルから親モデルへの暗黙的な1対1の関係を追加することによって実装されます。
モデルが関連するクラスという1つの位置引数が必要です。 これは、 ForeignKey の場合とまったく同じように機能し、 recursive および lazy の関係に関するすべてのオプションが含まれます。
OneToOneFieldに related_name 引数を指定しない場合、Djangoは現在のモデルの小文字の名前をデフォルト値として使用します。
次の例では：
from django.conf import settings
from django.db import models
class MySpecialUser(models.Model):
user = models.OneToOneField(
settings.AUTH_USER_MODEL,
on_delete=models.CASCADE,
)
supervisor = models.OneToOneField(
settings.AUTH_USER_MODEL,
on_delete=models.CASCADE,
related_name='supervisor_of',
)結果のUserモデルには、次の属性があります。
>>> user = User.objects.get(pk=1)
>>> hasattr(user, 'myspecialuser')
True
>>> hasattr(user, 'supervisor_of')
True関連するテーブルにエントリが存在しない場合、逆の関係にアクセスすると、DoesNotExist例外が発生します。 たとえば、ユーザーにMySpecialUserで指定されたスーパーバイザーがいない場合：
>>> user.supervisor_of
Traceback (most recent call last):
...
DoesNotExist: User matching query does not exist.さらに、OneToOneFieldは、 ForeignKey によって受け入れられるすべての追加の引数に加えて、1つの追加の引数を受け入れます。
Trueで、別の具象モデルを継承するモデルで使用される場合、このフィールドは、追加の [X193Xではなく、親クラスへのリンクとして使用する必要があることを示します。 ]これは通常、サブクラス化によって暗黙的に作成されます。OneToOneFieldの使用例については、 1対1の関係を参照してください。
Fieldは、データベーステーブルの列を表す抽象クラスです。 Djangoはフィールドを使用してデータベーステーブルを作成し（ db_type（））、Pythonタイプをデータベースにマップし（ get_prep_value（））、その逆も同様です（ from_db_value（）[X165X ]）。
したがって、フィールドは、さまざまなDjango API、特にモデルとクエリセットの基本的な部分です。
モデルでは、フィールドはクラス属性としてインスタンス化され、特定のテーブル列を表します。モデルを参照してください。 null や unique などの属性と、Djangoがフィールド値をデータベース固有の値にマップするために使用するメソッドがあります。
Fieldは RegisterLookupMixin のサブクラスであるため、 Transform と Lookup の両方を登録して、QuerySetで使用できます。 ] s（eg field_name__exact="foo"）。 すべての組み込みルックアップはデフォルトで登録されます。
CharField などのDjangoの組み込みフィールドはすべて、Fieldの特定の実装です。 カスタムフィールドが必要な場合は、組み込みフィールドのいずれかをサブクラス化するか、Fieldを最初から作成できます。 いずれの場合も、カスタムモデルフィールドの書き込みを参照してください。
フィールドの詳細な説明。例： django.contrib.admindocs アプリケーションの場合。
説明は次の形式にすることができます。
description = _("String (up to %(max_length)s)")ここで、引数はフィールドの__dict__から補間されます。
Fieldをデータベース固有のタイプにマップするために、Djangoはいくつかのメソッドを公開しています。
バックエンド固有の目的でこのフィールドに名前を付ける文字列を返します。 デフォルトでは、クラス名を返します。
カスタムフィールドでの使用については、組み込みフィールドタイプのエミュレートを参照してください。
connectionを考慮して、フィールドのデータベース列データ型を返します。
カスタムフィールドでの使用法については、カスタムデータベースタイプを参照してください。
connectionを考慮して、フィールドを指すForeignKeyやOneToOneFieldなどのフィールドのデータベース列データ型を返します。
カスタムフィールドでの使用法については、カスタムデータベースタイプを参照してください。
Djangoがデータベースのバックエンドおよびフィールドと対話する必要がある主な状況は3つあります。
データベースにクエリを実行するとき（Python値->データベースバックエンド値）
データベースからデータをロードするとき（データベースバックエンド値-> Python値）
データベースに保存するとき（Python値->データベースバックエンド値）
クエリを実行するときは、 get_db_prep_value（）および get_prep_value（）が使用されます。
valueはモデルの属性の現在の値であり、メソッドはクエリのパラメーターとして使用するために準備された形式でデータを返す必要があります。
使用法については、 Pythonオブジェクトをクエリ値に変換するを参照してください。
valueをバックエンド固有の値に変換します。 デフォルトでは、prepared=Trueの場合はvalueを返し、Falseの場合は get_prep_value（）を返します。
使用法については、クエリ値のデータベース値への変換を参照してください。
データをロードするとき、 from_db_value（）が使用されます：
データベースから返された値をPythonオブジェクトに変換します。 get_prep_value（）の逆です。
データベースバックエンドがすでに正しいPythonタイプを返すか、バックエンド自体が変換を行うため、このメソッドはほとんどの組み込みフィールドには使用されません。
使用法については、 Pythonオブジェクトへの値の変換を参照してください。
ノート
パフォーマンス上の理由から、from_db_valueは、それを必要としないフィールド（すべてのDjangoフィールド）でno-opとして実装されていません。 したがって、定義でsuperを呼び出すことはできません。
保存時には、 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にあります（これはフィールドによって設定されます）。
使用法については、保存前の値の前処理を参照してください。
フィールドは、シリアル化またはフォームのいずれかから、異なるタイプとして値を受け取ることがよくあります。
値を正しいPythonオブジェクトに変換します。 value_to_string（）の逆として機能し、 clean（）でも呼び出されます。
使用法については、 Pythonオブジェクトへの値の変換を参照してください。
データベースに保存するだけでなく、フィールドはその値をシリアル化する方法も知っている必要があります。
指定されたモデルインスタンスのフィールドの値を返します。
このメソッドは、 value_to_string（）でよく使用されます。
objを文字列に変換します。 フィールドの値をシリアル化するために使用されます。
使用法については、シリアル化のためのフィールドデータの変換を参照してください。
モデルフォームを使用する場合、Fieldは、どのフォームフィールドで表す必要があるかを知る必要があります。
ModelForm のこのフィールドのデフォルトの django.forms.Field を返します。
デフォルトでは、form_classとchoices_form_classの両方がNoneの場合、 CharField を使用します。 フィールドに choices があり、choices_form_classが指定されていない場合、 TypedChoiceField が使用されます。
使用法については、モデルフィールドのフォームフィールドの指定を参照してください。
フィールドを再作成するのに十分な情報を含む4タプルを返します。
モデルのフィールドの名前。
フィールドのインポートパス（例： "django.db.models.IntegerField"）。 これは最も移植性の高いバージョンである必要があるため、具体性が低い方がよい場合があります。
位置引数のリスト。
キーワード引数の辞書。
Migrations を使用してデータを移行するには、1.7より前のフィールドにこのメソッドを追加する必要があります。
すべてのFieldインスタンスには、その動作を内省できるいくつかの属性が含まれています。 フィールドの機能に依存するコードを記述する必要がある場合は、isinstanceチェックの代わりにこれらの属性を使用してください。 これらの属性を Model._meta API と一緒に使用して、特定のフィールドタイプの検索を絞り込むことができます。 カスタムモデルフィールドは、これらのフラグを実装する必要があります。
OneToOneFieldなど、フィールドが自動的に作成されたかどうかを示すブールフラグ。フィールドが別の非表示でないフィールドの機能をバックアップするために使用されているかどうかを示すブールフラグ（例： GenericForeignKeyを構成するcontent_typeおよびobject_idフィールド。 hiddenフラグは、モデル上のフィールドのパブリックサブセットを構成するものをモデル上のすべてのフィールドから区別するために使用されます。
ノート
Options.get_fields（）は、デフォルトで非表示フィールドを除外します。 include_hidden=Trueを渡して、結果の非表示フィールドを返します。
ForeignKey、ManyToManyField、OneToOneFieldなど）。modelはインスタンスのクラスではなく、スーパークラスを参照します。
これらの属性は、関係のカーディナリティおよびその他の詳細を照会するために使用されます。 これらの属性はすべてのフィールドに存在します。 ただし、フィールドがリレーションタイプ（ Field.is_relation = True ）の場合、ブール値（Noneではなく）のみが含まれます。
Trueのブールフラグ。 それ以外の場合はFalse。 これがTrueであるDjangoに含まれる唯一のフィールドは、ManyToManyFieldです。ForeignKeyなどの多対1の関係がある場合、Trueであるブールフラグ。 それ以外の場合はFalse。GenericRelationやForeignKeyの逆など、1対多の関係がある場合は、Trueのブールフラグ。 それ以外の場合はFalse。OneToOneFieldなどの1対1の関係がある場合、Trueであるブールフラグ。 それ以外の場合はFalse。ForeignKey(Author, on_delete=models.CASCADE)のAuthor。 GenericForeignKeyのrelated_modelは、常にNoneです。
