model reference ` のドキュメントには、Djangoの標準フィールドクラスの使用方法が説明されています--:class:`~django.db.models.CharField`や、:class:`~django.db.models.DateField などです。多くの目的、それらのクラスはあなたが必要とするすべてです。 ただし、Djangoバージョンが正確な要件を満たしていない場合や、Djangoに同梱されているものとはまったく異なるフィールドを使用したい場合があります。
\nDjangoの組み込みフィールドタイプは、可能なすべてのデータベース列タイプをカバーしているわけではありません-VARCHAR や INTEGER などの一般的なタイプのみです。 地理的なポリゴンや、 PostgreSQL custom types`_などのユーザー作成タイプなど、より不明瞭な列タイプについては、独自のDjangoの ``Field` サブクラスを定義できます。
あるいは、標準のデータベース列タイプに適合するように何らかの方法でシリアル化できる複雑なPythonオブジェクトがある場合があります。 これは Field サブクラスがオブジェクトをモデルで使用するのに役立つ別のケースです。
カスタムフィールドを作成するには、詳細に少し注意する必要があります。 物事をわかりやすくするために、このドキュメント全体で一貫した例を使用します: Bridge_の手でカードの取引を表すPythonオブジェクトをラップします。 心配しないでください。この例に従うためにBridgeをプレイする方法を知る必要はありません。 52枚のカードが、伝統的に*北*、東、*南*および*西*と呼ばれる4人のプレイヤーに均等に配られることだけを知っておく必要があります。 クラスは次のようになります:
\nclass Hand:\n """A hand of cards (bridge style)"""\n\n def __init__(self, north, east, south, west):\n # Input parameters are lists of cards ('Ah', '9s', etc.)\n self.north = north\n self.east = east\n self.south = south\n self.west = west\n\n # ... (other possibly useful methods omitted) ...\nこれは通常のPythonクラスであり、Django固有のクラスはありません。モデルで次のようなことができるようにしたいです（モデルの hand 属性は Hand のインスタンスであると仮定しています）:
example = MyModel.objects.get(pk=1)\nprint(example.hand.north)\n\nnew_hand = Hand(north, east, south, west)\nexample.hand = new_hand\nexample.save()\n他のPythonクラスと同様に、モデルの hand 属性に割り当てたり、そこから取得したりします。コツは、そのようなオブジェクトの保存と読み込みの処理方法をDjangoに伝えることです。
モデルで Hand クラスを使用するために、このクラスを変更する必要はありません。 これは、ソースコードを変更できない既存のクラスのモデルサポートを簡単に記述できるため、理想的です。
モデルフィールドの最も簡単な考え方は、これは通常のPythonオブジェクト -- 文字列、ブール値、 datetimeオブジェクト、または Handオブジェクトなどのより複雑なもの -- を取得し、データベースで扱うときに便利なフォーマットに変換したり、元に戻したりする方法を提供するということです。（それとシリアル化ですが、後で説明するように、データベース側を制御できるようになるとかなり自然にわかります）
\nモデルのフィールドは、何らかの方法で既存のデータベース列タイプに適合するように変換する必要があります。 データベースが異なれば有効な列タイプのセットも異なりますが、ルールは同じです。使用する必要があるのはこれらのタイプのみです。 データベースに保存するものはすべて、これらのタイプのいずれかに収まる必要があります。
\n通常、特定のデータベース列タイプに一致するDjangoフィールドを記述するか、データを文字列などに変換するかなり簡単な方法があります。
\nHand の例では、すべてのカードをあらかじめ決められた順序で連結することで、カードデータを104文字の文字列に変換できます。たとえば、すべての*北*カード、次に*東* 、*南*および*西*カードです。 したがって、Hand オブジェクトをデータベースのテキストまたは文字列に保存できます。
Djangoのすべてのフィールド（およびこのドキュメントで fields と言うときは、常に form fields ではなくモデルフィールドを意味します）は:class:django.db.models.Field のサブクラスです。 Djangoがフィールドについて記録する情報のほとんどは、名前、ヘルプテキスト、一意性など、すべてのフィールドに共通です。 すべての情報を保存することは Field によって処理されます。 Field ができることの詳細については、後で詳しく説明します。 とりあえず、すべてが Field から派生し、クラスの動作の重要な部分をカスタマイズすると言うだけで十分です。
Djangoフィールドクラスは、モデル属性に格納されているものではないことを理解することが重要です。 モデル属性には通常のPythonオブジェクトが含まれます。 モデルで定義するフィールドクラスは、モデルクラスが作成されるときに実際に Meta クラスに保存されます（これを行う方法の正確な詳細はここでは重要ではありません）。 これは、属性を作成および変更するだけの場合、フィールドクラスは必要ないためです。 代わりに、属性値とデータベースに保存されているもの、または serializer に送信されるものとの間で変換するための機構を提供します。
独自のカスタムフィールドを作成する場合は、このことに留意してください。 作成するDjangoの Field サブクラスは、Pythonインスタンスとデータベース/シリアライザーの値をさまざまな方法で変換するための機構を提供します（たとえば、値の保存とルックアップでの値の使用には違いがあります）。 これが少しトリッキーに聞こえる場合でも、心配しないでください。以下の例で明らかになります。 カスタムフィールドが必要な場合、しばしば2つのクラスを作成することになります:
最初のクラスは、ユーザーが操作するPythonオブジェクトです。彼らはそれをモデル属性に割り当て、そのようなものを表示するためにそれから読み込みます。これは、この例の Hand クラスです。
2番目のクラスは Field サブクラスです。これは、最初のクラスを永続ストレージ形式とPython形式の間で変換する方法を知っているクラスです。
When planning your Field subclass, first give some\nthought to which existing Field class your new field\nis most similar to. Can you subclass an existing Django field and save yourself\nsome work? If not, you should subclass the Field\nclass, from which everything is descended.
新しいフィールドの初期化は、ケース固有の引数を共通の引数から分離し、後者を Field の __init__() メソッドに渡すことです。 （または親クラスに対して）。
In our example, we'll call our field HandField. (It's a good idea to call\nyour Field subclass <Something>Field, so it's\neasily identifiable as a Field subclass.) It doesn't\nbehave like any existing field, so we'll subclass directly from\nField:
from django.db import models\n\nclass HandField(models.Field):\n\n description = "A hand of cards (bridge style)"\n\n def __init__(self, *args, **kwargs):\n kwargs['max_length'] = 104\n super().__init__(*args, **kwargs)\nOur HandField accepts most of the standard field options (see the list\nbelow), but we ensure it has a fixed length, since it only needs to hold 52\ncard values plus their suits; 104 characters in total.
The Field.__init__() method takes the following parameters:
name
rel: 関連フィールドに使用される (ForeignKey など)。上級者向けです。
serialize: False の場合、Django の serializers にモデルが渡されたときに、フィールドをシリアライズしません。デフォルトの値は True です。
もしバックエンドが tablespaces をサポートする場合、db_tablespace: はインデックスの作成のみ行います。通常、このオプションは無視できます。
モデル継承で使用される OneToOneField のように、フィールドが自動的に作成された場合は、auto_created は True です。 高度な使用向けです。
上記のリストに説明のないオプションはすべて、通常のDjangoフィールドと同じ意味を持ちます。例と詳細については、 field documentation を参照してください。
\nThe counterpoint to writing your __init__() method is writing the\ndeconstruct() method. It's used during model migrations to tell Django how to take an instance of your new field\nand reduce it to a serialized form - in particular, what arguments to pass to\n__init__() to re-create it.
継承元のフィールドの上に追加のオプションを追加していない場合、新しい deconstruct() メソッドを記述する必要はありません。 ただし、__init__() で渡される引数を変更する場合（HandField のように）、渡される値を補足する必要があります。
deconstruct() のコントラクトは単純です。 フィールドの属性名、フィールドクラスの完全なインポートパス、位置引数（リストとして）、キーワード引数（辞書として）の4つの項目のタプルを返します。 これは、3つのタプルを返す``deconstruct()`` メソッド:ref:for custom classes <custom-deconstruct-method> とは異なることに注意してください。
カスタムフィールドの作成者は、最初の2つの値を気にする必要はありません。 ベース Field クラスには、フィールドの属性名とインポートパスを計算するためのすべてのコードがあります。 ただし、位置引数とキーワード引数は、変更する可能性が高いため、注意する必要があります。
たとえば、 HandField クラスでは、常に __init__() でmax_lengthを強制的に設定しています。 Field ベースクラスの deconstruct() メソッドはこれを見て、キーワード引数でそれを返そうとします。 したがって、読みやすくするためにキーワード引数から削除できます:
from django.db import models\n\nclass HandField(models.Field):\n\n def __init__(self, *args, **kwargs):\n kwargs['max_length'] = 104\n super().__init__(*args, **kwargs)\n\n def deconstruct(self):\n name, path, args, kwargs = super().deconstruct()\n del kwargs["max_length"]\n return name, path, args, kwargs\n新しいキーワード引数を追加する場合、自分で kwargs に値を設定する deconstruct() でコードを記述する必要があります。 また、デフォルト値が使用されている場合など、フィールドの状態を再構築する必要がない場合は、kwargs から値を省略してください:
from django.db import models\n\nclass CommaSepField(models.Field):\n "Implements comma-separated storage of lists"\n\n def __init__(self, separator=",", *args, **kwargs):\n self.separator = separator\n super().__init__(*args, **kwargs)\n\n def deconstruct(self):\n name, path, args, kwargs = super().deconstruct()\n # Only include kwarg if it's not the default\n if self.separator != ",":\n kwargs['separator'] = self.separator\n return name, path, args, kwargs\nMore complex examples are beyond the scope of this document, but remember -\nfor any configuration of your Field instance, deconstruct() must return\narguments that you can pass to __init__ to reconstruct that state.
Pay extra attention if you set new default values for arguments in the\nField superclass; you want to make sure they're always included, rather\nthan disappearing if they take on the old default value.
さらに、値を位置引数として返さないようにしてください。 可能な限り、将来の互換性を最大限にするために、キーワード引数として値を返します。 もちろん、コンストラクターの引数リストでの位置よりも頻繁に引数の名前を変更する場合、位置を好むかもしれませんが、人々はかなり長い間（おそらく何年も）シリアル化されたバージョンからフィールドを再構築することに注意してください、 移行の存続期間によって異なります。
\nフィールドを含む移行を調べることで分解の結果を確認できます。フィールドを分解して再構築するだけで、単体テストで分解をテストできます:
\nname, path, args, kwargs = my_field_instance.deconstruct()\nnew_instance = MyField(*args, **kwargs)\nself.assertEqual(my_field_instance.some_attribute, new_instance.some_attribute)\nDjangoは変更を検出して移行を行わないため、カスタムフィールドの基本クラスを変更することはできません。たとえば、次で始まる場合:
\nclass CustomCharField(models.CharField):\n ...\nそして、代わりに TextField を使用することに決めた場合、サブクラスを次のように変更することはできません:
class CustomCharField(models.TextField):\n ...\n代わりに、新しいカスタムフィールドクラスを作成し、モデルを更新してそれを参照する必要があります:
\nclass CustomCharField(models.CharField):\n ...\n\nclass CustomTextField(models.TextField):\n ...\nAs discussed in removing fields, you\nmust retain the original CustomCharField class as long as you have\nmigrations that reference it.
As always, you should document your field type, so users will know what it is.\nIn addition to providing a docstring for it, which is useful for developers,\nyou can also allow users of the admin app to see a short description of the\nfield type via the django.contrib.admindocs application. To do this simply provide\ndescriptive text in a description class attribute of your custom\nfield. In the above example, the description displayed by the admindocs\napplication for a HandField will be 'A hand of cards (bridge style)'.
In the django.contrib.admindocs display, the field description is\ninterpolated with field.__dict__ which allows the description to\nincorporate arguments of the field. For example, the description for\nCharField is:
description = _("String (up to %(max_length)s)")\n Field サブクラスを作成したら、フィールドの動作に応じて、いくつかの標準メソッドをオーバーライドすることを検討できます。以下のメソッドのリストは、おおよそ重要度の高いものから順に並んでいるので、上から始めてください。
Say you've created a PostgreSQL custom type called mytype. You can\nsubclass Field and implement the db_type() method, like so:
from django.db import models\n\nclass MytypeField(models.Field):\n def db_type(self, connection):\n return 'mytype'\nMytypeField を取得したら、他の``Field`` タイプと同様に、どのモデルでも使用できます:
class Person(models.Model):\n name = models.CharField(max_length=80)\n something_else = MytypeField()\nIf you aim to build a database-agnostic application, you should account for\ndifferences in database column types. For example, the date/time column type\nin PostgreSQL is called timestamp, while the same column in MySQL is called\ndatetime. The simplest way to handle this in a db_type()\nmethod is to check the connection.settings_dict['ENGINE'] attribute.
例:
\nclass MyDateField(models.Field):\n def db_type(self, connection):\n if connection.settings_dict['ENGINE'] == 'django.db.backends.mysql':\n return 'datetime'\n else:\n return 'timestamp'\nThe db_type() and rel_db_type() methods are called by\nDjango when the framework constructs the CREATE TABLE statements for your\napplication -- that is, when you first create your tables. The methods are also\ncalled when constructing a WHERE clause that includes the model field --\nthat is, when you retrieve data using QuerySet methods like get(),\nfilter(), and exclude() and have the model field as an argument. They\nare not called at any other time, so it can afford to execute slightly complex\ncode, such as the connection.settings_dict check in the above example.
Some database column types accept parameters, such as CHAR(25), where the\nparameter 25 represents the maximum column length. In cases like these,\nit's more flexible if the parameter is specified in the model rather than being\nhard-coded in the db_type() method. For example, it wouldn't make much\nsense to have a CharMaxlength25Field, shown here:
# This is a silly example of hard-coded parameters.\nclass CharMaxlength25Field(models.Field):\n def db_type(self, connection):\n return 'char(25)'\n\n# In the model:\nclass MyModel(models.Model):\n # ...\n my_field = CharMaxlength25Field()\nこれを行うより良い方法は、実行時、つまりクラスがインスタンス化されるときにパラメーターを指定可能にすることです。そのためには、次のように``Field.__init__()`` を実装するだけです：
\n# This is a much more flexible example.\nclass BetterCharField(models.Field):\n def __init__(self, max_length, *args, **kwargs):\n self.max_length = max_length\n super().__init__(*args, **kwargs)\n\n def db_type(self, connection):\n return 'char(%s)' % self.max_length\n\n# In the model:\nclass MyModel(models.Model):\n # ...\n my_field = BetterCharField(25)\nFinally, if your column requires truly complex SQL setup, return None from\ndb_type(). This will cause Django's SQL creation code to skip\nover this field. You are then responsible for creating the column in the right\ntable in some other way, of course, but this gives you a way to tell Django to\nget out of the way.
The rel_db_type() method is called by fields such as ForeignKey\nand OneToOneField that point to another field to determine their database\ncolumn data types. For example, if you have an UnsignedAutoField, you also\nneed the foreign keys that point to that field to use the same data type:
# MySQL unsigned integer (range 0 to 4294967295).\nclass UnsignedAutoField(models.AutoField):\n def db_type(self, connection):\n return 'integer UNSIGNED AUTO_INCREMENT'\n\n def rel_db_type(self, connection):\n return 'integer UNSIGNED'\nIf your custom Field class deals with data structures that are more\ncomplex than strings, dates, integers, or floats, then you may need to override\nfrom_db_value() and to_python().
If present for the field subclass, from_db_value() will be called in all\ncircumstances when the data is loaded from the database, including in\naggregates and values() calls.
to_python() is called by deserialization and during the\nclean() method used from forms.
As a general rule, to_python() should deal gracefully with any of the\nfollowing arguments:
An instance of the correct type (e.g., Hand in our ongoing example).
文字列
None (フィールドが null=True を許す場合)
In our HandField class, we're storing the data as a VARCHAR field in the\ndatabase, so we need to be able to process strings and None in the\nfrom_db_value(). In to_python(), we need to also handle Hand\ninstances:
import re\n\nfrom django.core.exceptions import ValidationError\nfrom django.db import models\nfrom django.utils.translation import gettext_lazy as _\n\ndef parse_hand(hand_string):\n """Takes a string of cards and splits into a full hand."""\n p1 = re.compile('.{26}')\n p2 = re.compile('..')\n args = [p2.findall(x) for x in p1.findall(hand_string)]\n if len(args) != 4:\n raise ValidationError(_("Invalid input for a Hand instance"))\n return Hand(*args)\n\nclass HandField(models.Field):\n # ...\n\n def from_db_value(self, value, expression, connection):\n if value is None:\n return value\n return parse_hand(value)\n\n def to_python(self, value):\n if isinstance(value, Hand):\n return value\n\n if value is None:\n return value\n\n return parse_hand(value)\nNotice that we always return a Hand instance from these methods. That's the\nPython object type we want to store in the model's attribute.
For to_python(), if anything goes wrong during value conversion, you should\nraise a ValidationError exception.
Since using a database requires conversion in both ways, if you override\nto_python() you also have to override get_prep_value()\nto convert Python objects back to query values.
例:
\nclass HandField(models.Field):\n # ...\n\n def get_prep_value(self, value):\n return ''.join([''.join(l) for l in (value.north,\n value.east, value.south, value.west)])\nSome data types (for example, dates) need to be in a specific format\nbefore they can be used by a database backend.\nget_db_prep_value() is the method where those conversions should\nbe made. The specific connection that will be used for the query is\npassed as the connection parameter. This allows you to use\nbackend-specific conversion logic if it is required.
For example, Django uses the following method for its\nBinaryField:
def get_db_prep_value(self, value, connection, prepared=False):\n value = super().get_db_prep_value(value, connection, prepared)\n if value is not None:\n return connection.Database.Binary(value)\n return value\nIn case your custom field needs a special conversion when being saved that is\nnot the same as the conversion used for normal query parameters, you can\noverride get_db_prep_save().
If you want to preprocess the value just before saving, you can use\npre_save(). For example, Django's\nDateTimeField uses this method to set the attribute\ncorrectly in the case of auto_now or\nauto_now_add.
If you do override this method, you must return the value of the attribute at\nthe end. You should also update the model's attribute if you make any changes\nto the value so that code holding references to the model will always see the\ncorrect value.
\nTo customize the form field used by ModelForm, you can\noverride formfield().
The form field class can be specified via the form_class and\nchoices_form_class arguments; the latter is used if the field has choices\nspecified, the former otherwise. If these arguments are not provided,\nCharField or TypedChoiceField\nwill be used.
All of the kwargs dictionary is passed directly to the form field's\n__init__() method. Normally, all you need to do is set up a good default\nfor the form_class (and maybe choices_form_class) argument and then\ndelegate further handling to the parent class. This might require you to write\na custom form field (and even a form widget). See the forms documentation for information about this.
Continuing our ongoing example, we can write the formfield() method\nas:
class HandField(models.Field):\n # ...\n\n def formfield(self, **kwargs):\n # This is a fairly standard way to set up some defaults\n # while letting the caller override them.\n defaults = {'form_class': MyFormField}\n defaults.update(kwargs)\n return super().formfield(**defaults)\nThis assumes we've imported a MyFormField field class (which has its own\ndefault widget). This document doesn't cover the details of writing custom form\nfields.
If you have created a db_type() method, you don't need to worry about\nget_internal_type() -- it won't be used much. Sometimes, though, your\ndatabase storage is similar in type to some other field, so you can use that\nother field's logic to create the right column.
例:
\nclass HandField(models.Field):\n # ...\n\n def get_internal_type(self):\n return 'CharField'\nNo matter which database backend we are using, this will mean that\nmigrate and other SQL commands create the right column type for\nstoring a string.
If get_internal_type() returns a string that is not known to Django for\nthe database backend you are using -- that is, it doesn't appear in\ndjango.db.backends.<db_name>.base.DatabaseWrapper.data_types -- the string\nwill still be used by the serializer, but the default db_type()\nmethod will return None. See the documentation of db_type()\nfor reasons why this might be useful. Putting a descriptive string in as the\ntype of the field for the serializer is a useful idea if you're ever going to\nbe using the serializer output in some other place, outside of Django.
To customize how the values are serialized by a serializer, you can override\nvalue_to_string(). Using value_from_object() is the\nbest way to get the field's value prior to serialization. For example, since\nHandField uses strings for its data storage anyway, we can reuse some\nexisting conversion code:
class HandField(models.Field):\n # ...\n\n def value_to_string(self, obj):\n value = self.value_from_object(obj)\n return self.get_prep_value(value)\nWriting a custom field can be a tricky process, particularly if you're doing\ncomplex conversions between your Python types and your database and\nserialization formats. Here are a couple of tips to make things go more\nsmoothly:
\nLook at the existing Django fields (in\ndjango/db/models/fields/__init__.py) for inspiration. Try to find\na field that's similar to what you want and extend it a little bit,\ninstead of creating an entirely new field from scratch.
Put a __str__() method on the class you're wrapping up as a field. There\nare a lot of places where the default behavior of the field code is to call\nstr() on the value. (In our examples in this document, value would\nbe a Hand instance, not a HandField). So if your __str__()\nmethod automatically converts to the string form of your Python object, you\ncan save yourself a lot of work.
FileField subclassLink to this heading#In addition to the above methods, fields that deal with files have a few other\nspecial requirements which must be taken into account. The majority of the\nmechanics provided by FileField, such as controlling database storage and\nretrieval, can remain unchanged, leaving subclasses to deal with the challenge\nof supporting a particular type of file.
Django provides a File class, which is used as a proxy to the file's\ncontents and operations. This can be subclassed to customize how the file is\naccessed, and what methods are available. It lives at\ndjango.db.models.fields.files, and its default behavior is explained in the\nfile documentation.
Once a subclass of File is created, the new FileField subclass must be\ntold to use it. To do so, simply assign the new File subclass to the special\nattr_class attribute of the FileField subclass.
In addition to the above details, there are a few guidelines which can greatly\nimprove the efficiency and readability of the field's code.
\nThe source for Django's own ImageField (in\ndjango/db/models/fields/files.py) is a great example of how to\nsubclass FileField to support a particular type of file, as it\nincorporates all of the techniques described above.
Cache file attributes wherever possible. Since files may be stored in\nremote storage systems, retrieving them may cost extra time, or even\nmoney, that isn't always necessary. Once a file is retrieved to obtain\nsome data about its content, cache as much of that data as possible to\nreduce the number of times the file must be retrieved on subsequent\ncalls for that information.