Django 1.11.6 文档

首页 | 目录 | 索引 | 模块

« 上一页 | 上一级 | 下一页 »

模型字段参考

本文档包含了Django提供的字段的全部API参考，包括字段选项 和 字段类型。

另请参见

如果内置字段没有这样做，你可以尝试django-地方风味（文档），其中包含对特定国家有用的各种代码段及文化。

当然，你也可以很容易的编写你的自定义模型字段。

注

技术上来说, 这些模型定义于 django.db.models.fields, 但为了方便起见它们被导入到django.db.models; 标准惯例是用 from django.db import models ，涉及到字段时用 models.<Foo>Field.

字段选项

下列参数是全部字段类型都可用的， 而且都是可选择的。

null

Field.null

如果为True，Django将在数据库中将空值存储为NULL。 默认值是 False。

避免在基于字符串的字段（例如CharField和TextField上使用null。 如果字符串字段的null=True，那意味着对于“无数据”有两个可能的值：NULL 和空字符串。 在大多数情况下，对于“无数据”声明两个值是赘余的，Django 的惯例是使用空字符串而不是NULL。 一个例外是当CharField同时具有unique=True和blank=True时。 在这种情况下，需要null=True，以便在使用空白值保存多个对象时避免唯一的约束违规。

无论是字符串字段还是非字符串字段，如果你希望在表单中允许空值，你将还需要设置blank=True，因为null 仅仅影响数据库存储（参见blank）。

注

在使用Oracle 数据库时，数据库将存储NULL 来表示空字符串，而与这个属性无关。

如果你希望BooleanField 接受null 值，请用 NullBooleanField 代替。

blank

Field.blank

如果为True，则该字段允许为空白。 默认值是 False。

注意它与null不同。 null 纯粹是数据库范畴的概念，而blank 是数据验证范畴的。 如果字段设置blank=True，表单验证时将允许输入空值。 如果字段设置blank=False，则该字段为必填。

choices

Field.choices

它是一个可迭代的结构(比如，列表或是元组)，由可迭代的二元组组成(比如[(A, B), (A, B) ...])，用来给这个字段提供选择项。 如果设置了 choices ，默认表格样式就会显示选择框，而不是标准的文本框，而且这个选择框的选项就是 choices 中的元组。

每个元组中的第一个元素，是存储在数据库中的值；第二个元素是使人容易理解的描述。 比如：

YEAR_IN_SCHOOL_CHOICES = (
    ('FR', 'Freshman'),
    ('SO', 'Sophomore'),
    ('JR', 'Junior'),
    ('SR', 'Senior'),
)

一般来说，最好在模型类内部定义choices，然后再给每个值定义一个合适名字的常量。

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)

尽管你可以在模型类的外部定义choices然后引用它，但是在模型类中定义choices和其每个choice的name(即元组的第二个元素)可以保留所有使用该choices的类的信息， 也使得choices更容易被引用（例如， Student.SOPHOMORE 可以在任何引入Student 模型的位置生效)。

你也可以归类可选的choices到已命名的组中用来达成组织整理的目的:

MEDIA_CHOICES = (
    ('Audio', (
            ('vinyl', 'Vinyl'),
            ('cd', 'CD'),
        )
    ),
    ('Video', (
            ('vhs', 'VHS Tape'),
            ('dvd', 'DVD'),
        )
    ),
    ('unknown', 'Unknown'),
)

每个元组的第一个元素是组的名字。 第二个元素是一组可迭代的二元元组，每个二元元组包含一个值和一个易读的名字，构成一个选项。 已分组的选项可能会和未分组的选项合在同一个list中。 （就像例中的unknown选项）。

对于有choices 属性的模型字段, Django 将会加入一个方法来获取当前字段值的易于理解的名称 参见数据库API文档中的get_FOO_display()。

请注意choices可以是任何可迭代的对象 – 不是必须是列表或者元组。 这一点使你可以动态的构建choices。 但是如果你发现你自己搞不定动态的choices，你最好还是使用ForeignKey来构建一个合适的数据库表。 如果是这样，choices更适合那些变动不多的静态数据。

除非blank=False 和default一起在字段中被设置，否则，可选择菜单将会有"---------" 的标签。 要重写这个行为, 需要加入一个包含None的元组到 choices里面; 例如 (None, 'Your String For Display'). 或者, 在可行的情况下用一个空字符串代替None - 比如在一个 字符串字段.

db_column

Field.db_column

数据库中用来表示该字段的列名称。 如果未指定，那么Django将会使用字段名作为列名.

如果您的数据库列名称是SQL保留字，或包含Python变量名称中不允许的字符，特别是连字符，那也没关系。 Django在幕后引用列和表名。

db_index

Field.db_index

如果True，将为该字段创建一个数据库索引。

db_tablespace

Field.db_tablespace

如果该字段有索引的话，数据库database tablespace的名称将作为该字段的索引名。 如果DEFAULT_INDEX_TABLESPACE 已经设置，则默认值是由DEFAULT_INDEX_TABLESPACE指定, 如果没有设置则由 db_tablespace 指定， 如果后台数据库不支持索引的tablespaces，则该选项被忽略

default

Field.default

该字段的默认值. 它可以是一个值或者一个可调用对象. 如果是一个可调用对象，那么在每一次创建新对象的时候，它将会调用一次.

默认值不能是可变对象（模型实例list，set等。），因为对该对象的同一实例的引用将被用作所有新模型实例中的默认值。 或者，把他们包装为一个可调用的对象。 例如，如果要为JSONField指定默认dict，请使用以下函数：

def contact_default():
    return {"email": "to1@example.com"}

contact_info = JSONField("ContactInfo", default=contact_default)

匿名函数不能用于类似default的字段选项，因为它们不能serialized by migrations. 请参见文档其他部分。

对于映射到模型实例的ForeignKey等字段，默认值应该是它们引用的字段的值（pk，除非设置了to_field），而不是模型实例。

默认值会在新实例创建并且没有给该字段提供值时使用。 如果字段为主键，默认值也会在设置为None时使用。

editable

Field.editable

如果设为False，则这个字段将不会出现在admin或者其他ModelForm中。 模型验证也会跳过它们。 默认是True。

error_messages

Field.error_messages

error_messages 参数能够让你重写抛出的默认错误信息。 通过关键字，在字典中匹配你要重写的错误信息。

error_messages 的 key 值包括 unique, unique_for_date, invalid, blank, null, 和 invalid_choice. 其余的 error_messages 的 keys 在不同的章节下 Field types是不一样的。

这些错误消息通常不会传播到表单。 参见Considerations regarding model’s error_messages。

help_text

Field.help_text

额外的 ‘help' 文本将被显示在表单控件form中。 即便你的字段没有应用到一个form里面，这样的操作对文档化也很有帮助。

注意在自动生成的表单中，这个值不会进行HTML转义。 如果真的需要，应该在help_text中包含HTML。 例如：

help_text="Please use the following format: <em>YYYY-MM-DD</em>."

另外, 你可以使用简单文本和django.utils.html.escape()以避免任何HTML特定的字符. 请确保你所使用的help text能够避免那些由不受信任的用户进行的跨站点脚本攻击。

primary_key

Field.primary_key

若为 True, 则该字段会成为模型的主键字段。

如果你没有在模型的任何字段上指定 primary_key=True, Django会自动添加一个 AutoField 字段来充当主键。 所以除非你想要覆盖默认的主键行为，否则不需要在任何字段上设定primary_key=True 。 更多内容 请参考 Automatic primary key fields.

primary_key=True 暗含着null=False 和unique=True. 一个对象上只能拥有一个主键.

主键字段是只读的。 如果你改变了一个已存在对象上的主键并且保存的话，会创建一个新的对象，而不是覆盖旧的.

unique

Field.unique

如果为 True, 这个字段在表中必须有唯一值.

这是一个在数据库级别的强制性动作,并且通过模型来验证。 如果你试图用一个重复的值来保存unique 字段，那么一个django.db.IntegrityError就会通过模型的save() 函数抛出来。

此选项对除ManyToManyField和OneToOneField之外的所有字段类型均有效。

注意当设置unique 为True 时，你不需要再指定 db_index，因为unique 本身就意味着一个索引的创建。

在Django 1.11中的更改：

在旧版本中，unique=True不能用于FileField。

unique_for_date

Field.unique_for_date

当设置它为DateField 和DateTimeField 字段的名称时，表示要求该字段对于相应的日期字段值是唯一的。

例如，你有一个title 字段设置unique_for_date="pub_date"，那么Django 将不允许两个记录具有相同的title 和pub_date。

注意，如果你将它设置为DateTimeField，只会考虑其日期部分。 此外，如果USE_TZ 为True，检查将以对象保存时的current time zone 进行。

这是在模型验证期间通过Model.validate_unique() 强制执行的，而不是在数据库层级进行验证。 如果unique_for_date 约束涉及的字段不是ModelForm中的字段（例如，exclude中列出的字段或者设置了editable=False），Model.validate_unique() 将忽略该特殊的约束。

unique_for_month

Field.unique_for_month

类似unique_for_date，只是要求字段对于月份是唯一的。

unique_for_year

Field.unique_for_year

类似unique_for_date 和 unique_for_month。

verbose_name

Field.verbose_name

一个字段的可读性更高的名称。 如果没有给定自述名，Django会根据字段属性名，将下划线转换为空格自动创建它。 参见字段的自述名。

validators

Field.validators

该字段将要运行的一个Validator 的列表。 更多信息参见validators documentation。

注册和获取查找

Field 实现了lookup registration API。 该API 可以用于自定义一个字段类型的可用的查询，以及如何从一个字段获取查询。

字段类型

AutoField

class AutoField(**options)

一个根据实际ID自动增长的IntegerField . 你通常不需要直接使用它；如果没有另外指定，主键字段将自动添加到您的模型中。 详细查看 Automatic primary key fields.

BigAutoField

class BigAutoField(**options)

Django中的新功能1.10。

一个64位整数，非常像AutoField，除了它保证适合1到9223372036854775807之间的数字。

BigIntegerField

class BigIntegerField(**options)

一个64位整数，非常像IntegerField，除了它保证适合从-9223372036854775808到9223372036854775807的数字。 这个字段默认的表单组件是一个TextInput.

BinaryField

class BinaryField(**options)

这是一个用来存储原始二进制码的Field. 只支持bytes 赋值， 注意这个Field只有很有限的功能。 例如，不大可能在一个BinaryField 值的数据上进行查询 在ModelForm中也不可能包含BinaryField。

滥用BinaryField

尽管你可能想使用数据库来存储你的文件，但是99%的情况下这都是不好的设计。 这个字段 不是替代static files 的合理操作.

BooleanField

class BooleanField(**options)

true/false 字段。

此字段的默认表单挂件是一个CheckboxInput.

如果你需要设置null 值，则使用NullBooleanField 来代替BooleanField。

如果Field.default没有指定的话， BooleanField 的默认值是 None。

CharField

class CharField(max_length=None, **options)

一个用来存储从小到很大各种长度的字符串的地方

如果是巨大的文本类型, 可以用 TextField.

这个字段默认的表单组件是一个TextInput.

CharField必须接收一个额外的参数:

CharField.max_length

字段的最大字符长度. max_length将在数据库层和Django表单验证中起作用, 用来限定字段的长度.

注

如果你在写一个需要导出到多个不同数据库后端的应用，你需要注意某些后端对max_length有一些限制， 查看database backend notes来获取更多的细节

CommaSeparatedIntegerField

class CommaSeparatedIntegerField(max_length=None, **options)

自1.9版以来已弃用 这个字段不利于CharField与validators=[ validate_comma_separated_integer_list ]。

一个逗号分隔的整数字段。 像 CharField一样， 需要一个max_length 参数， 同时数据库移植时也需要注意。

DateField

class DateField(auto_now=False, auto_now_add=False, **options)

这是一个使用Python的datetime.date实例表示的日期. 有几个额外的设置参数:

DateField.auto_now

每次保存对象时，自动设置该字段为当前时间。 用于"最后一次修改"的时间戳。 请注意，当前日期为始终使用；它不只是一个可以覆盖的默认值。

调用Model.save()时，该字段才会自动更新。 当以其他方式更新其他字段（例如QuerySet.update()）时，该字段不会更新，尽管您可以为此类型的更新指定字段的自定义值。

DateField.auto_now_add

当对象第一次被创建时自动设置当前时间。 用于创建时间的时间戳. 请注意，始终使用当前日期；它是一个可以覆盖的默认值。 因此，即使您在创建对象时为此字段设置了一个值，也将被忽略。 如果您想要修改此字段，请设置以下代替auto_now_add=True：

• 对于DateField：default=date.today - 从datetime.date.today()
• 对于DateTimeField：default=timezone.now - 从django.utils.timezone.now()

这个字段默认的表单组件是一个TextInput. 在管理员站点添加了一个JavaScript写的日历控件，和一个“Today"的快捷按钮. 包含了一个额外的invalid_date错误消息键.

default, auto_now, and auto_now_add 这些设置是相互排斥的. 他们之间的任何组合将会发生错误的结果.

注

在目前的实现中，设置auto_now或者auto_now_add为True将导致这个字段同时具有editable=False和blank=True这两个设置.

注

在对象创建或更新时，auto_now和auto_now_add这两个设置将始终使用default timezone(默认时区)的日期。 如果你需要不同的东西，你可能只想使用自己的可调用的默认值或者覆盖save()而不是使用auto_now或auto_now_add；或使用DateTimeField代替DateField，并决定如何在显示时处理从datetime到date的转换。

DateTimeField

class DateTimeField(auto_now=False, auto_now_add=False, **options)

它是通过Python datetime.datetime实例表示的日期和时间. 携带了跟DateField一样的额外参数.

该字段默认对应的表单控件是一个单个的TextInput(单文本输入框). 管理界面是使用两个带有 JavaScript控件的 TextInput 文本框.

DecimalField

class DecimalField(max_digits=None, decimal_places=None, **options)

用python中 Decimal 的一个实例来表示十进制浮点数. 有两个 必须的参数:

DecimalField.max_digits

位数总数，包括小数点后的位数。 该值必须大于等于decimal_places.

DecimalField.decimal_places

小数点后的数字数量

例如,要保存最大为 999 并有两位小数的数字,你应该使用:

models.DecimalField(..., max_digits=5, decimal_places=2)

而要存储那些将近10亿，并且要求达到小数点后十位精度的数字:

models.DecimalField(..., max_digits=19, decimal_places=10)

当localize为False或TextInput时，该字段的默认表单小部件是NumberInput。

注

想获取更多关于 FloatField 和 DecimalField 差异, 请参照 FloatField vs. DecimalField.

DurationField

class DurationField(**options)

用作存储一段时间的字段类型 - 类似Python中的timedelta. 当数据库使用的是PostgreSQL, 该数据类型使用的是一个 interval 而在Oracle上，则使用的是 INTERVAL DAY(9) TO SECOND(6). 否则使用微秒的bigint。

注

DurationField 的算数运算在多数情况下可以很好的工作。 然而，在除了PostgreSQL之外的其他数据库中, 将 DurationField 与 DateTimeField 的实例比较则不会得到正确的结果。

EmailField

class EmailField(max_length=254, **options)

一个 CharField 用来检查输入的email地址是否合法。 它使用 EmailValidator 来验证输入合法性。

FileField

class FileField(upload_to=None, max_length=100, **options)

上传文件字段。

注

不支持primary_key参数，如果使用将引发错误。

有两个可选参数：

FileField.upload_to

该属性提供设置上传目录和文件名的方式，可以通过两种方式进行设置。 在这两种情况下，值都将传递到Storage.save()方法。

如果指定一个字符串值，它可以包含strftime()的格式，这个格式将被文件上传的日期/时间替换（这样上传的文件不会填满给定的目录）。 例如：

class MyModel(models.Model):
    # 文件将上传到MEDIA_ROOT/uploads
    upload = models.FileField(upload_to='uploads/')
    # 或者...
    # 文件将保存到MEDIA_ROOT/uploads/2015/01/30
    upload = models.FileField(upload_to='uploads/%Y/%m/%d/')

如果使用默认的FileSystemStorage，则字符串值将附加到MEDIA_ROOT路径中形成文件系统上的位置用于保存上传的文件。 如果使用的是其它存储，请检查该存储的文档，了解它如何处理upload_to。

upload_to也可以是可调用的对象，例如函数。 这将被调用来生成上传路径，包括文件名。 此可调用必须接受两个参数，并返回一个Unix样式的路径（带有斜杠），以便传递到存储系统。 两个参数是：

参数	描述
instance	FileField定义所在的模型的实例。 更准确地说，就是当前文件所在的那个实例。 大部分情况下，这个实例还没有保存到数据库中，若它用到默认的AutoField字段，它的主键字段还可能没有值。
filename	最初给文件的文件名。 当确定最终目的地路径时，这可能或可能不被考虑。

例如：

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)

FileField.storage

一个Storage 对象，用于你的文件的存取。 关于如何提供这个对象的细节，参见管理文件。

这个字段的默认表单Widget 是ClearableFileInput。

在模型中调用FileField 或 ImageField (见下方) 需如下几步：

1. 在你的settings文件中, 你必须要定义 MEDIA_ROOT 作为Django存储上传文件的路径 (从性能上考虑，这些文件不能存在数据库中。) 定义一个 MEDIA_URL 作为基础的URL或者目录。 确保这个目录可以被web server使用的账户写入。
2. 在模型中添加FileField或ImageField字段, 定义upload_to选项来指定MEDIA_ROOT的一个子目录用于存放上传的文件。
3. 数据库中存放的仅是这个文件的路径（相对于MEDIA_ROOT）。 你很可能会想用由Django提供的便利的url属性。 比如说, 如果你的ImageField命名为mug_shot, 你可以在template中用{{ object.mug_shot.url }}获得你照片的绝对路径。

例如，如果你的 MEDIA_ROOT设定为 '/home/media'，并且 upload_to设定为 'photos/%Y/%m/%d'。 upload_to的'%Y/%m/%d'是strftime()格式；'%Y'是四位数年份，'%m'是两位数的月份，'%d'是两位数的天数。 如果你在Jan.15.2007上传了一个文件，它将被保存在/home/media/photos/2007/01/15目录下。

如果要检索上传的文件的磁盘文件名或文件大小，则可以分别使用name和size属性；有关可用属性和方法的更多信息，请参见File类参考和管理文件主题指南。

注

保存的文件作为模型存储在数据库中的一部分，所以在磁盘上使用的实际的文件名在模型保存完毕之前是不可靠的。

上传的文件对应的URL可以通过使用 url 属性获得. 在内部，它会调用 Storage 类下的url()方法.

值得注意的是，无论你在任何时候处理上传文件的需求，你都应该密切关注你的文件将被上传到哪里，上传的文件类型，以避免安全漏洞。 认证所有上传文件 以确保那些上传的文件是你所认为的文件。 例如，如果你盲目的允许其他人在无需认证的情况下上传文件至你的web服务器的root目录中，那么别人可以上传一个CGI或者PHP脚本然后通过访问一个你网站的URL来执行这个脚本。 所以，不要允许这种事情发生。

甚至是上传HTML文件也值得注意，它可以通过浏览器（虽然不是服务器）执行，也可以引发相当于是XSS或者CSRF攻击的安全威胁。

FileField 实例将会在你的数据库中创建一个默认最大长度为100字符的varchar 列。 就像其他的fields一样, 你可以用 max_length 参数改变最大长度的值.

FileField 和 FieldFile

class FieldFile

当你添加 FileField 到你的模型中时, 你实际上会获得一个 FieldFile的实例来替代将要访问的文件。

FieldFile的API反映了File的API，其中一个不同之处在于： 由类包装的对象不一定是围绕Python的内置文件对象的包装。 Instead, it is a wrapper around the result of the Storage.open() method, which may be a File object, or it may be a custom storage’s implementation of the File API.

除了File继承的API，例如read()和write()，FieldFile包含几种方法可用于与底层文件交互：

警告

该类的两种方法save()和delete()，默认保存数据库中关联的FieldFile的模型对象。

FieldFile.name

该文件的名称包括相关的FileField的Storage根的相对路径。

FieldFile.size

底层Storage.size()方法的结果。

FieldFile.url

该文件的URL，它是一个只读属性，通过调用底层Storage类的url()方法得到。

FieldFile.open(mode='rb')

在指定的mode中打开或重新打开与该实例关联的文件。 与标准Python open()方法不同，它不返回文件描述符。

由于底层文件在访问时隐含打开，因此除了将指针重置到底层文件或更改mode之外，可能无需调用此方法。

FieldFile.close()

该方法像标准的Pythonfile.close() 方法,并关闭相关文件.

FieldFile.save(name, content, save=True)

这个方法会将文件名以及文件内容传递到字段的storage类中,并将模型字段与保存好的文件关联. 如果想要手动关联文件数据到你的模型中的 FileField实例, 则save() 方法总是用来保存该数据.

方法接受两个必选参数: name 文件名, 和 content 文件内容. 可选参数save 控制模型实例在关联的文件被修改时是否保存. 默认为 True.

注意参数 content 应该是 django.core.files.File的一个实例, 而不是Python内建的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")

更多信息, 请参见 Managing files.

FieldFile.delete(save=True)

删除与此实例关联的文件，并清除该字段的所有属性。 注意︰ 如果它碰巧是开放的调用 delete() 方法 时，此方法将关闭该文件。

可选参数save控制模型实例在与此字段关联的在文件删除后是否保存。 默认为 True.

注意，model删除的时候，与之关联的文件并不会被删除。 如果你要把文件也清理掉，你需要自己处理。

FilePathField

class FilePathField(path=None, match=None, recursive=False, max_length=100, **options)

一个 CharField ，内容只限于文件系统内特定目录下的文件名。 有三个参数, 其中第一个是 必需的:

FilePathField.path

必填。 这个FilePathField 应该得到其选择的目录的绝对文件系统路径。 例如: "/home/images".

FilePathField.match

可选的. FilePathField 将会作为一个正则表达式来匹配文件名。 但请注意正则表达式将将被作用于基本文件名，而不是完整路径。 例如： "foo.*\.txt$"，它将匹配一个名为foo23.txt但不是bar.txt或foo23.png的文件。

FilePathField.recursive

可选的. True 或 False. 默认值是 False。 声明是否包含所有子目录的path

FilePathField.allow_files

可选的. True 或 False. 默认是True. 声明是否包含指定位置的文件。 该参数或allow_folders 中必须有一个为 True.

FilePathField.allow_folders

可选的. True 或 False. 默认值是 False。 声明是否包含指定位置的文件夹。 该参数或 allow_files 中必须有一个为 True.

当然，这些参数可以同时使用。

有一点需要提醒的是 match只匹配基本文件名（base filename）, 而不是整个文件路径（full path）. 例如:

FilePathField(path="/home/images", match="foo.*", recursive=True)

...将匹配/home/images/foo.png，但不符合/home/images/foo/bar.png，因为match适用于基本文件名（foo.png和bar.png）。

FilePathField实例被创建在您的数据库为varchar列默认最大长度为 100 个字符。 就像其他的fields一样, 你可以用 max_length 参数改变最大长度的值.

FloatField

class FloatField(**options)

用Python的一个float 实例来表示一个浮点数.

当localize为False或TextInput时，该字段的默认表单小部件是NumberInput。

FloatField 与DecimalField

有时候FloatField 类会和DecimalField 类发生混淆. 虽然它们表示都表示实数，但是二者表示数字的方式不一样。 FloatField 使用的是Python内部的 float 类型, 而DecimalField 使用的是Python的 Decimal 类型. 想要了解更多二者的差别, 可以查看Python文档中的 decimal 模块.

ImageField

class ImageField(upload_to=None, height_field=None, width_field=None, max_length=100, **options)

继承FileField的所有属性和方法，但还对上传的对象进行校验，确保它是个有效的图片。

除了从FileField继承来的属性外，ImageField 还有height和 width属性。

为了方便查询属性, ImageField有两个额外的可选参数。

ImageField.height_field

模型字段的名称，在模型实例每次保存时将自动填写为图片的高度。

ImageField.width_field

模型字段的名称，在模型实例每次保存时将自动填写为图片的宽度。

需要Pillow库。

ImageField在你的数据库中创建为varchar列，默认最大长度为100个字符。 类似其它fields，你可以用max_length参数改变最大长度。

这个字段的默认表单Widget是ClearableFileInput。

IntegerField

class IntegerField(**options)

一个整数。 在Django所支持的所有数据库中，从 -2147483648 到 2147483647 范围内的值是合法的。 当localize为False或TextInput时，该字段的默认表单小部件是NumberInput。

GenericIPAddressField

class GenericIPAddressField(protocol='both', unpack_ipv4=False, **options)

一个 IPv4 或 IPv6 地址, 字符串格式 (例如 192.0.2.30 或 2a02:42fe::4). 这个字段默认的表单组件是一个TextInput.

IPv6地址规范化遵循 RFC 4291#section-2.2第2.2节，包括使用该段第3段中建议的IPv4格式，如::ffff:192.0.2.0 例如，::ffff:0a0a:0a0a将被归一化为2001::1和2001:0::0:01 ::ffff:10.10.10.10。 所有字符都转换为小写。

GenericIPAddressField.protocol

限制指定协议的有效输入。 接受的值为'IPv6'（默认值），'IPv4'或'both'。 匹配不区分大小写。

GenericIPAddressField.unpack_ipv4

解析IPv4映射地址如 ::ffff:192.0.2.1. 如果启用该选项，则地址将被解析到192.0.2.1. 默认为禁用。 只有当protocol 设置为'both'时才可以使用。

如果允许空白值，则必须允许null值，因为空白值存储为null。

NullBooleanField

class NullBooleanField(**options)

类似BooleanField, 但是允许 NULL 作为一个选项. 使用此代替null=True的BooleanField。 此字段的默认表单widget为NullBooleanSelect。

PositiveIntegerField

class PositiveIntegerField(**options)

类似 IntegerField, 但值必须是正数或者零(0). 从0到2147483647的值在Django支持的所有数据库中都是安全的。 由于向后兼容性原因，接受值0。

PositiveSmallIntegerField

class PositiveSmallIntegerField(**options)

该模型字段类似 PositiveIntegerField, 但是只允许小于某一特定值（依据数据库类型而定）。 从0 到 32767 这个区间，对于Django所支持的所有数据库而言都是安全的。

SlugField

class SlugField(max_length=50, **options)

Slug 是一个新闻术语（通常叫做短标题）。 一个slug只能包含字母、数字、下划线或者是连字符，通常用来作为短标签。 通常它们是用来放在URL里的。

像CharField一样，你可以指定max_length（也请参阅该部分中的有关数据库可移植性的说明和max_length）。 如果没有指定 max_length, Django将会默认长度为50。

将Field.db_index设置为True。

根据某些其他值的值自动预填充SlugField通常很有用。 你可以在admin中使用prepopulated_fields自动执行此操作。

SlugField.allow_unicode

如果True，该字段除了ASCII字母外还接受Unicode字母。 默认为False。

SmallIntegerField

class SmallIntegerField(**options)

Like an IntegerField, but only allows values under a certain (database-dependent) point. IntegerField 对于django来讲，该字段值在 -32768 至 32767这个范围内对所有可支持的数据库都是安全的。

TextField

class TextField(**options)

大文本字段。 该模型默认的表单组件是Textarea。

如果你在这个字段类型中使用了max_length属性，它将会在渲染页面表单元素Textarea 时候体现出来。 但是并不会在model或者数据库级别强制性的限定字段长度。 请使用CharField。

TimeField

class TimeField(auto_now=False, auto_now_add=False, **options)

时间字段，和Python中 datetime.time 一样。 接受与DateField相同的自动填充选项。

这个字段默认的表单组件是一个TextInput. Admin添加一些JavaScript快捷方式。

URLField

class URLField(max_length=200, **options)

一个CharField 类型的URL

这个字段默认的表单组件是一个TextInput.

与所有CharField子类一样，URLField接受可选的max_length参数。 如果不指定max_length，则使用默认值200。

UUIDField

class UUIDField(**options)

一个用来存储UUID的字段。 使用Python的UUID类。 当使用PostgreSQL数据库时，该字段类型对应的数据库中的数据类型是uuid，使用其他数据库时，数据库对应的是char(32)类型。

primary_key用AutoField的另外一个好的选择就是UUID。 数据库不会自动生成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 fields

注意：这里传递给default是一个可调用的对象（即一个省略了括号的方法），而不是传递一个default实例给UUID

关联关系字段

Django还定义一系列字段来描述数据库之间的关联。

ForeignKey

class ForeignKey(to, on_delete, **options)

多对一关系。 要求两个位置参数：模型相关的类和on_delete选项。 （on_delete实际上并不是必需的，但不提供它会给出已废弃的警告。 在Django 2.0中将需要它。）

若要创建递归关联关系 — 一个对象与自己具有多对一关联关系 — 请使用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 = True

production/models.py

from django.db import models
from products.models import AbstractCar

class Manufacturer(models.Model):
    pass

class Car(AbstractCar):
    pass

# Car.manufacturer将指向这里的`production.Manufacturer`。

若要引用在其它应用中定义的模型，你可以用带有完整标签名的模型来显式指定。 例如，如果上面的Manufacturer模型是在一个名为production的应用中定义的，你应该这样使用它：

class Car(models.Model):
    manufacturer = models.ForeignKey(
        'production.Manufacturer',
        on_delete=models.CASCADE,
    )

这种称为懒惰关系的引用在解析两个应用程序之间的循环导入依赖关系时可能很有用。

ForeignKey 会自动创建数据库索引。 你可以通过设置db_index 为False 来取消。 如果你创建外键是为了一致性而不是用来Join，或者如果你将创建其它索引例如部分或多列索引，你也许想要避免索引的开销。

数据库表示

在幕后，Django 会在字段名上添加"_id" 来创建数据库中的列名。 在上面的例子中，Car 模型的数据库表将会拥有一个manufacturer_id 列。 （你可以通过指定db_column来显式更改）但是，除非你编写自定义SQL，否则代码不应该处理数据库列名。 你应该永远只处理你的模型对象中的字段名称。

参数

ForeignKey接受定义关系如何工作的细节的其他参数。

ForeignKey.on_delete

当删除由ForeignKey引用的对象时，Django将模拟由on_delete参数指定的SQL约束的行为。 例如，如果你有一个可以为空的ForeignKey，在其引用的对象被删除的时你想把这个ForeignKey 设置为空：

user = models.ForeignKey(
    User,
    models.SET_NULL,
    blank=True,
    null=True,
)

自1.9版以来已弃用 on_delete将成为Django 2.0中必需的参数。 在旧版本中，默认为CASCADE。

on_delete 在django.db.models中可以找到的值有：

• CASCADE

  级联删除。 Django模拟SQL约束ON DELETE CASCADE的行为，并删除包含ForeignKey的对象。

• PROTECT

  抛出ProtectedError 以阻止被引用对象的删除，它是django.db.IntegrityError 的一个子类。

• SET_NULL

  设置ForeignKey null；只有null是True才有可能。

• SET_DEFAULT

  将ForeignKey设置为其默认值；必须设置ForeignKey的默认值。

• SET()

  设置ForeignKey 为传递给SET() 的值，如果传递的是一个可调用对象，则为调用后的结果。 在大部分情形下，传递一个可调用对象用于避免models.py 在导入时执行查询：

  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),
      )
  

• DO_NOTHING

  不采取任何动作。 如果您的数据库后端强制引用完整性，除非手动添加SQL ON DELETE约束，否则将导致IntegrityError到数据库字段。

ForeignKey.limit_choices_to

当这个字段使用ModelForm或者Admin 渲染时（默认情况下，查询集中的所有对象都可以使用），为这个字段设置一个可用的选项。 它可以是一个字典、一个Q 对象或者一个返回字典或Q对象的可调用对象。

像这样：

staff_member = models.ForeignKey(
    User,
    on_delete=models.CASCADE,
    limit_choices_to={'is_staff': True},
)

这将使得在ModelForm对应的字段只列出Users 的is_staff=True 这在Django 的Admin 中也可能有用处。

可调用对象的形式同样非常有用，比如与Python 的datetime模块一起使用来限制选择的时间范围。 像这样：

def limit_pub_date_choices():
    return {'pub_date__lte': datetime.date.utcnow()}

limit_choices_to = limit_pub_date_choices

如果ModelAdmin 自己本身是或者返回一个用于complex queries的Q object，当字段没有在模型的limit_choices_to中的raw_id_fields 列出时，它将只会影响Admin中的可用的选项。

注

如果limit_choices_to 使用可调用对象，这个可调用对象将在每次创建一个新表单的时候都调用。 它还可能在一个模型校验的时候调用，例如被管理命令或者Admin。 Admin 多次构造查询集来验证表单在各种边缘情况下的输入，所以你的可调用对象可能调用多次。

ForeignKey.related_name

这个名称用于让关联的对象反查到源对象。 它还是related_query_name 的默认值（关联的模型进行反向过滤时使用的名称）。 完整的解释和示例参见related objects documentation。 请注意，在abstract models定义关系时，必须设置此值；当您这样做some special syntax。

如果你不想让Django 创建一个反向关联，请设置'+' 为 '+' 或者以related_name 结尾。 例如，下面这行将确定User 模型将不会有到这个模型的返回关联：

user = models.ForeignKey(
    User,
    on_delete=models.CASCADE,
    related_name='+',
)

ForeignKey.related_query_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支持通过some special syntax的应用程序标签和类插值。

ForeignKey.to_field

关联到的关联对象的字段名称。 默认地，Django 使用关联对象的主键。 如果引用其他字段，该字段必须具有unique=True。

ForeignKey.db_constraint

控制是否在数据库中为这个外键创建约束。 默认值为True，这几乎是你想要的；将此设置为False可能对数据完整性非常不利。 即便如此，有一些场景你也许想要这么设置：

• 你有遗留的无效数据。
• 你正在对数据库缩容。

如果被设置成False，访问一个不存在的关联对象将抛出 DoesNotExist 异常。

ForeignKey.swappable

如果该ForeignKey 指向一个可切换swappable的模型,该属性控制迁移框架的行为 如果它是默认值True，那么如果ForeignKey 指向的模型与settings.AUTH_USER_MODEL 匹配（或其它可切换的模型），该关联关系会被保存在迁移migration中，且使用的是对setting 中引用而不是直接对模型的引用。

只有当你确定你的模型将永远指向切换后的模型 —— 例如如果它是专门为你的自定义用户模型设计的模型时，你才会想将它设置成False。

设置为False 并不表示你可以引用可切换的模型即使在它被切换出去之后 —— False 只是表示生成的迁移中ForeignKey 将始终引用你指定的准确模型（所以，如果用户试图允许一个你不支持的User 模型时将会失败）。

如果有疑问，请保留它的默认值True。

ManyToManyField

class ManyToManyField(to, **options)

一个多对多关联。 要求一个关键字参数：与该模型关联的类，与ForeignKey 的工作方式完全一样，包括recursive 和lazy。

关联的对象可以通过字段的RelatedManager 添加、删除和创建。

数据库表示

在幕后，Django 创建一个中间表来表示多对多关系。 默认情况下，这张中间表的名称使用多对多字段的名称和包含这张表的模型的名称生成。 因为某些数据库支持的表的名字的长度有限制，这些表的名称将自动截短到64 个字符并加上一个唯一性的哈希值。 这意味着你可能会看到像author_books_9cdf4这样的表名；这是完全正常的。 你可以使用db_table选项手工提供中间表的名称。

参数

ManyToManyField 接收一个参数集来控制关联关系的功能 —— 它们都是可选的。

ManyToManyField.related_name

与ForeignKey.related_name 相同。

ManyToManyField.related_query_name

与ForeignKey.related_query_name 相同。

ManyToManyField.limit_choices_to

与ForeignKey.limit_choices_to 相同。

ManyToManyField 对于使用through 参数自定义中间表的limit_choices_to 不生效。

ManyToManyField.symmetrical

只用于与自身进行关联的ManyToManyField。 例如下面的模型：

from django.db import models

class Person(models.Model):
    friends = models.ManyToManyField("self")

当Django 处理这个模型的时候，它定义该模型具有一个与自身具有多对多关联的ManyToManyField，因此它不会向person_set 类添加Person 属性。 Django 将假定这个ManyToManyField 字段是对称的 —— 如果我是你的朋友，那么你也是我的朋友。

如果你希望与self 进行多对多关联的关系不具有对称性，可以设置symmetrical 为False。 这会强制让Django 添加一个描述器给反向的关联关系，以使得ManyToManyField 的关联关系不是对称的。

ManyToManyField.through

Django 会自动创建一个表来管理多对多关系。 不过，如果你希望手动指定中介表，可以使用through 选项来指定Django 模型来表示你想要使用的中介表。

这个选项最常见的使用场景是当你想要关联更多的数据到关联关系的时候。

如果你没有显式指定through 的模型，仍然会有一个隐式的through 模型类，你可以用它来直接访问对应的表示关联关系的数据库表。 它由三个字段来链接模型。

如果源模型和目标不同，则生成以下字段：

• id：关系的主键。
• <containing_model>_id：声明了ManyToManyField的模型的id
• <other_model>_id: 被ManyToManyField所指向的模型的id

如果ManyToManyField 的源模型和目标模型相同，则生成以下字段：

• id：关系的主键。
• from_<model>_id：源模型实例的id。
• to_<model>_id：目标模型实例的id。

这个类可以让一个给定的模型像普通的模型那样查询与之相关联的记录。

ManyToManyField.through_fields

只能在指定了自定义中间模型的时候使用。 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有两个 foreign keys指向 Person (person and inviter), 这样会导致关系不清晰，Django不知道使用哪一个外键。 在这种情况下，你必须使用through_fields 明确指定Django 应该使用哪些外键，就像上面例子一样。

through_fields 接受一个2元数组 ('field1', 'field2'), 其中 field1是指向定义了ManyToManyField的那个model的 foreign key的名字(在本例中就是group，它自己定义了M2M字段，同时也在中间模型中被ForeignKey所指向 ), and field2就是目标模型的foreign key 的名字 (person in this case).

当中间模型具有多个外键指向多对多关联关系模型中的任何一个（或两个），你必须 指定through_fields。 这通用适用于recursive relationships，当用到中间模型而有多个外键指向该模型时，或当你想显式指定Django 应该用到的两个字段时。

递归的关联关系使用的中间模型始终定义为非对称的，也就是symmetrical=False —— 所以具有源和目标的概念。 这种情况下，'field1' 将作为管理关系的源，而'field2' 作为目标。

ManyToManyField.db_table

为存储多对多数据而创建的表的名称。 如果没有提供，Django 将基于定义关联关系的模型和字段假设一个默认的名称。

ManyToManyField.db_constraint

控制中间表中的外键是否创建约束。 默认值为True，这几乎是你想要的；将此设置为False可能对数据完整性非常不利。 即便如此，有一些场景你也许想要这么设置：

• 你有遗留的无效数据。
• 你正在对数据库缩容。

不可以同时传递db_constraint 和 through。

ManyToManyField.swappable

控制ManyToManyField 指向一个可切换的模型时迁移框架的行为。 如果它是默认值True，那么如果ManyToManyField 指向的模型与settings.AUTH_USER_MODEL 匹配（或其它可切换的模型），则保存在迁移中的关联关系将使用对setting 中引用而不是直接对模型的引用。

只有当你确定你的模型将永远指向切换后的模型 —— 例如如果它是专门为你的自定义用户模型设计的模型时，你才会想将它设置成False。

如果有疑问，请保留它的默认值True。

ManyToManyField 不支持validators。

null 不生效，因为无法在数据库层次要求关联关系。

OneToOneField

class OneToOneField(to, on_delete, parent_link=False, **options)

一对一关联关系。 概念上讲，这个字段类似ForeignKey设置了unique=True，不同的是关联关系的另一边会直接返回单个对象。

当一个模型的主键在某种程度上“扩展”另一个模型时，这是最有用的；例如，多表继承是通过将一个隐式一对一关系从子模型添加到父模型来实现的。

需要一个位置参数：与该模型关联的类。 它的工作方式与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 异常。 例如，如果一个User没有MySpecialUser指定的supervisor：

>>> user.supervisor_of
Traceback (most recent call last):
    ...
DoesNotExist: User matching query does not exist.

另外，OneToOneField 除了接收ForeignKey 接收的所有额外的参数之外，还有另外一个参数：

OneToOneField.parent_link

当它为True并在继承自另一个具体模型的模型中使用时，表示该字段应该用于反查的父类的链接，而不是在子类化时隐式创建的OneToOneField。

OneToOneField的使用示例参见One-to-one关联关系。

字段API参考

class Field

Field 是一个抽象的类, 用来代表数据库中的表的一列. Django使用字段创建数据库表（db_type()），将Python类型映射到数据库（get_prep_value()），反之亦然（from_db_value()

field 是不同Django版本API中最根本的部分，尤其是models and querysets.

在模型中，一个字段被实例化为类的属性，并表现为一个特定的表的列，详情查看Models. 它具有null和unique等属性，以及Django用于将字段值映射到数据库特定值的方法。

field_name__exact="foo"是RegisterLookupMixin的子类，因此可以在其上注册Transform和Lookup QuerySet s（例如Field）。 默认情况下，所有built-in lookups都已注册。

Django的所有内建字段，如CharField都是Field的特定实现。 如果您需要自定义字段，则可以将任何内置字段子类化，也可以从头开始写入Field。 无论哪种情况，请参阅Writing custom model fields。

description

字段的详细说明，例如用于django.contrib.admindocs应用程序。

描述可以是以下形式：

description = _("String (up to %(max_length)s)")

其中参数从字段的__dict__插入。

要将Field映​​射到数据库特定类型，Django会公开几种方法：

get_internal_type()

返回一个字符串，命名此字段以用于后端特定用途。 默认情况下，它返回类名。

有关自定义字段中的用法，请参见Emulating built-in field types。

db_type(connection)

返回Field的数据库列数据类型，同时考虑connection。

有关自定义字段中的用法，请参见Custom database types。

rel_db_type(connection)

Django中的新功能1.10。

返回指向Field的字段的数据库列数据类型，例如ForeignKey和OneToOneField，考虑connection

有关自定义字段中的用法，请参见Custom database types。

有三种主要情况，Django需要与数据库后端和字段交互：

• 当它查询数据库（Python值 转为 数据库后端值）
• 当它从数据库加载数据（数据库后端值 转为 Python值）
• 当它保存到数据库（Python值 转为 数据库后端值）

查询时，使用get_db_prep_value()和get_prep_value()：

get_prep_value(value)

value是模型属性的当前值，方法应以已准备好用作查询中的参数的格式返回数据。

有关使用方式，请参阅Converting Python objects to query values。

get_db_prep_value(value, connection, prepared=False)

将value转换为后端特定值。 如果False和get_prep_value() if为prepared=True，则默认返回value。

有关用法，请参见Converting query values to database values。

加载数据时，使用from_db_value()：

from_db_value(value, expression, connection, context)

将数据库返回的值转换为Python对象。 它与get_prep_value()相反。

此方法不用于大多数内置字段，因为数据库后端已返回正确的Python类型，或后端本身执行转换。

有关用法，请参见Converting values to Python objects。

注

出于性能原因，from_db_value在不需要它的字段（所有Django字段）上不实现为无操作。 因此，您不能在定义中调用super。

保存时，使用pre_save()和get_db_prep_save()

get_db_prep_save(value, connection)

与get_db_prep_value()相同，但在字段值必须保存到数据库时调用。 默认返回get_db_prep_value()。

pre_save（model_instance，add）

在get_db_prep_save()之前调用方法以在保存之前准备值（例如，对于DateField.auto_now）。

model_instance是此字段所属的实例，add是实例是否第一次保存到数据库。

它应该返回此字段的model_instance适当属性的值。 属性名称位于self.attname（这是由Field设置）。

有关使用情况，请参阅Preprocessing values before saving。

字段经常从不同的类型接收它们的值，从序列化或从表单。

to_python(value)

改变这个值为正确的python对象。 它作为value_to_string()的反向操作，也在clean()中调用。

有关用法，请参见Converting values to Python objects。

除了保存到数据库，该字段还需要知道如何序列化其值：

value_to_string(obj)

将obj转换为字符串。 用于序列化字段的值。

有关用法，请参见Converting field data for serialization。

当使用model forms时，Field需要知道应由哪个表单字段表示：

formfield(form_class=None, choices_form_class=None, **kwargs)

返回ModelForm的此字段的默认django.forms.Field。

默认情况下，如果form_class和choices_form_class都是None，则使用CharField。 如果没有指定choices和choices_form_class，则使用TypedChoiceField。

有关用法，请参见Specifying the form field for a model field。

deconstruct()

返回具有足够信息的4元组，以重新创建字段：

1. 模型上字段的名称。
2. 字段的导入路径（例如"django.db.models.IntegerField"）。 这应该是兼容的版本，所以不要太具体可能会更好。
3. 位置参数列表。
4. 关键字参数的字典。

必须将此方法添加到1.7之前的字段，才能使用Migrations迁移其数据。

字段属性参考

每个Field实例包含几个允许内省其行为的属性。 使用这些属性而不是isinstance检查何时需要编写取决于字段功能的代码。 这些属性可与Model._meta API一起使用，以缩小特定字段类型的搜索范围。 自定义模型字段应实现这些标志。

字段的属性

Field.auto_created

布尔标志，指示是否自动创建字段，例如模型继承使用的OneToOneField。

Field.concrete

布尔标志，指示字段是否具有与其相关联的数据库列。

Field.hidden

布尔标志，指示是否使用字段来回复另一个非隐藏字段的功能（例如，构成GenericForeignKey的object_id和content_type ）。 hidden标志用于区分模型上的公共字段子集构成模型上的所有字段。

注

Options.get_fields()默认排除隐藏字段。 传入include_hidden=True可返回结果中的隐藏字段。

Field.is_relation

布尔标志，指示字段是否包含对其功能的一个或多个其他模型的引用（例如，ForeignKey，ManyToManyField，OneToOneField等。）。

Field.model

返回定义字段的模型。 如果在模型的超类上定义了字段，则model将引用超类，而不是实例的类。

关系字段的属性

这些属性用于查询关系的基数和其他详细信息。 这些属性存在于所有字段中；但是，如果该字段是关系类型（Field.is_relation=True），它们将只有布尔值（而不是None）。

Field.many_to_many

如果该字段具有多对多关系，则为True的布尔标志；否则False。 Django中包含的仅有True的字段为ManyToManyField。

Field.many_to_one

如果该字段具有多对一关系，例如ForeignKey，则为True的布尔标志； False否则。

Field.one_to_many

如果该字段具有一对多关系，例如GenericRelation或ForeignKey的相反，则为True的布尔标志； False否则。

Field.one_to_one

如果字段具有一对一的关系，例如OneToOneField，则为True的布尔标志； False否则。

Field.related_model

指向字段涉及的模型。 例如，ForeignKey（作者， on_delete = models.CASCADE）中的Author。 GenericForeignKey的related_model始终为None。

最后更新：

2017年9月6日

« 上一页 | 上一级 | 下一页 »