模型字段参考

本文档包含了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

避免在基于字符串的字段(例如CharFieldTextField上使用null 如果字符串字段的null=True,那意味着对于“无数据”有两个可能的值:NULL 和空字符串。 在大多数情况下,对于“无数据”声明两个值是赘余的,Django 的惯例是使用空字符串而不是NULL 一个例外是当CharField同时具有unique=Trueblank=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=Falsedefault一起在字段中被设置,否则,可选择菜单将会有"---------" 的标签。 要重写这个行为, 需要加入一个包含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

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

默认值不能是可变对象(模型实例listset等。),因为对该对象的同一实例的引用将被用作所有新模型实例中的默认值。 或者,把他们包装为一个可调用的对象。 例如,如果要为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=Falseunique=True. 一个对象上只能拥有一个主键.

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

unique

Field.unique

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

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

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

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

在Django 1.11中的更改:

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

unique_for_date

Field.unique_for_date

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

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

注意,如果你将它设置为DateTimeField,只会考虑其日期部分。 此外,如果USE_TZTrue,检查将以对象保存时的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_dateunique_for_month

verbose_name

Field.verbose_name

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

validators

Field.validators

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

注册和获取查找

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

字段类型

AutoField

class AutoField(**options)[source]

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

BigAutoField

class BigAutoField(**options)[source]
Django中的新功能1.10。

一个64位整数,非常像AutoField,除了它保证适合19223372036854775807之间的数字。

BigIntegerField

class BigIntegerField(**options)[source]

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

BinaryField

class BinaryField(**options)[source]

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

滥用BinaryField

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

BooleanField

class BooleanField(**options)[source]

true/false 字段。

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

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

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

CharField

class CharField(max_length=None, **options)[source]

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

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

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

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

CharField.max_length

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

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

CommaSeparatedIntegerField

class CommaSeparatedIntegerField(max_length=None, **options)[source]

自1.9版以来已弃用 这个字段不利于CharFieldvalidators=[ validate_comma_separated_integer_list ]

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

DateField

class DateField(auto_now=False, auto_now_add=False, **options)[source]

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

DateField.auto_now

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

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

DateField.auto_now_add

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

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

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

在目前的实现中,设置True或者auto_now_addauto_now将为让这个字段同时得到editable=Falseblank=True这两个设置.

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

DateTimeField

class DateTimeField(auto_now=False, auto_now_add=False, **options)[source]

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

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

DecimalField

class DecimalField(max_digits=None, decimal_places=None, **options)[source]

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

localizeFalseTextInput时,该字段的默认表单小部件是NumberInput

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

DurationField

class DurationField(**options)[source]

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

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

EmailField

class EmailField(max_length=254, **options)[source]

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

FileField

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

上传文件字段。

不支持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

在模型中调用FileFieldImageField (见下方) 需如下几步:

  1. 在你的settings文件中, 你必须要定义 MEDIA_ROOT 作为Django存储上传文件的路径 (从性能上考虑,这些文件不能存在数据库中。) 定义一个 MEDIA_URL 作为基础的URL或者目录。 确保这个目录可以被web server使用的账户写入。
  2. 在模型中添加FileFieldImageField字段, 定义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目录下。

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

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

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

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

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

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

FileFieldFieldFile

class FieldFile[source]

当你添加 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

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

FieldFile.size

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

FieldFile.url

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

FieldFile.open(mode='rb')[source]

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

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

FieldFile.close()[source]

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

FieldFile.save(name, content, save=True)[source]

这个方法会将文件名以及文件内容传递到字段的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)[source]

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

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

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

FilePathField

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

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

FilePathField.path

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

FilePathField.match

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

FilePathField.recursive

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

FilePathField.allow_files

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

FilePathField.allow_folders

可选的. TrueFalse. 默认值是 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.pngbar.png)。

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

FloatField

class FloatField(**options)[source]

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

localizeFalseTextInput时,该字段的默认表单小部件是NumberInput

FloatFieldDecimalField

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

ImageField

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

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

除了从FileField继承来的属性外,ImageField 还有heightwidth属性。

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

ImageField.height_field

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

ImageField.width_field

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

需要Pillow库。

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

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

IntegerField

class IntegerField(**options)[source]

一个整数。 在Django所支持的所有数据库中,从 -21474836482147483647 范围内的值是合法的。 localizeFalseTextInput时,该字段的默认表单小部件是NumberInput

GenericIPAddressField

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

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

IPv6地址规范化遵循 RFC 4291#section-2.2第2.2节,包括使用该段第3段中建议的IPv4格式,如::ffff:192.0.2.0 例如,::ffff:0a0a:0a0a将被归一化为2001::12001: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)[source]

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

PositiveIntegerField

class PositiveIntegerField(**options)[source]

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

PositiveSmallIntegerField

class PositiveSmallIntegerField(**options)[source]

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

SlugField

class SlugField(max_length=50, **options)[source]

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)[source]

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

TextField

class TextField(**options)[source]

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

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

TimeField

class TimeField(auto_now=False, auto_now_add=False, **options)[source]

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

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

URLField

class URLField(max_length=200, **options)[source]

一个CharField 类型的URL

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

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

UUIDField

class UUIDField(**options)[source]

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

primary_keyAutoField的另外一个好的选择就是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)[source]

多对一关系。 要求两个位置参数:模型相关的类和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_indexFalse 来取消。 如果你创建外键是为了一致性而不是用来Join,或者如果你将创建其它索引例如部分或多列索引,你也许想要避免索引的开销。

数据库表示

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

参数¶ T0>

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_deletedjango.db.models中可以找到的值有:

  • CASCADE[source]

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

  • PROTECT[source]

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

  • SET_NULL[source]

    设置ForeignKey null;只有nullTrue才有可能。

  • SET_DEFAULT[source]

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

  • SET()[source]

    设置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[source]

    不采取任何动作。 如果您的数据库后端强制引用完整性,除非手动添加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对应的字段只列出Usersis_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 queriesQ 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_namedefault_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)[source]

一个多对多关联。 要求一个关键字参数:与该模型关联的类,与ForeignKey 的工作方式完全一样,包括recursivelazy

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

数据库表示

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

参数¶ T0>

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 进行多对多关联的关系不具有对称性,可以设置symmetricalFalse 这会强制让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_constraintthrough

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)[source]

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

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

需要一个位置参数:与该模型关联的类。 它的工作方式与ForeignKey 完全一致,包括所有与recursivelazy相关的选项。

如果你没有指定OneToOneFieldrelated_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 接收的所有额外的参数之外,还有另外一个参数:

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

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

字段API参考

class Field[source]

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

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

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

field_name__exact="foo"RegisterLookupMixin的子类,因此可以在其上注册TransformLookup 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()[source]

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

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

db_type(connection)[source]

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

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

rel_db_type(connection)[source]
Django中的新功能1.10。

返回指向Field的字段的数据库列数据类型,例如ForeignKeyOneToOneField,考虑connection

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

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

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

查询时,使用get_db_prep_value()get_prep_value()

get_prep_value(value)[source]

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

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

get_db_prep_value(value, connection, prepared=False)[source]

value转换为后端特定值。 如果Falseget_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)[source]

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

pre_savemodel_instanceadd[source]

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

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

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

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

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

to_python(value)[source]

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

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

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

value_to_string(obj)[source]

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

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

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

formfield(form_class=None, choices_form_class=None, **kwargs)[source]

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

默认情况下,如果form_classchoices_form_class都是None,则使用CharField 如果没有指定choiceschoices_form_class,则使用TypedChoiceField

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

deconstruct()[source]

返回具有足够信息的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

布尔标志,指示是否使用字段来回复另一个非隐藏字段的功能(例如,构成GenericForeignKeyobject_idcontent_type )。 hidden标志用于区分模型上的公共字段子集构成模型上的所有字段。

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

Field.is_relation

布尔标志,指示字段是否包含对其功能的一个或多个其他模型的引用(例如,ForeignKeyManyToManyFieldOneToOneField等。)。

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

如果该字段具有一对多关系,例如GenericRelationForeignKey的相反,则为True的布尔标志; False否则。

Field.one_to_one

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

Field.related_model

指向字段涉及的模型。 例如,ForeignKey(作者, on_delete = models.CASCADE)中的Author GenericForeignKeyrelated_model始终为None