django--模型字段引用

如果内置字段不起作用，您可以尝试使用django-localflavor（文档），其中包含对特定国家和文化有用的各种代码片段。

此外，您可以轻松编写自己的自定义模型字段。

注意

从技术上讲，这些模型是定义的django.db.models.fields，但为方便起见，它们被导入django.db.models; 标准惯例是使用和引用字段 。from django.db import modelsmodels.<Foo>Field

字段选项¶

以下参数可用于所有字段类型。所有都是可选的。

null¶

Field. null ¶

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

避免null在基于字符串的字段上使用，例如 CharField和TextField。如果基于字符串的字段具有 null=True，则表示它具有“无数据”的两个可能值：NULL和空字符串。在大多数情况下，为“无数据”提供两个可能的值是多余的; Django约定是使用空字符串，而不是 NULL。一个例外是当a 和CharFieldboth都设置了。在这种情况下，需要在使用空值保存多个对象时避免唯一约束违规。unique=Trueblank=Truenull=True

对于基于字符串和非基于字符串的字段，您还需要设置blank=True是否允许在表单中允许空值，因为该 null参数仅影响数据库存储（请参阅参考资料blank）。

注意

使用Oracle数据库后端时，NULL无论此属性如何，都将存储该值以表示空字符串。

blank¶

Field. blank ¶

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

请注意，这与...不同null。null纯粹与数据库相关，而blank与验证相关。如果字段有blank=True，则表单验证将允许输入空值。如果字段有blank=False，则需要该字段。

choices¶

Field. choices ¶

由两个项目（例如）的可迭代组成 的序列，用作该字段的选项。如果给出了选择，则通过模型验证强制执行，默认表单小部件将是具有这些选项而不是标准文本字段的选择框。[(A, B), (A, B) ...]

每个元组中的第一个元素是要在模型上设置的实际值，第二个元素是人类可读的名称。例如：

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元组包含一个值和一个人类可读的选项名称。分组选项可以与单个列表中的未分组选项组合（例如本示例中的 未知选项）。

对于已choices设置的每个模型字段，Django将添加一个方法来检索字段当前值的可读名称。请参阅 get_FOO_display()数据库API文档。

请注意，选择可以是任何序列对象 - 不一定是列表或元组。这使您可以动态构造选择。但是，如果你发现自己choices变得动态，你可能最好使用一个合适的数据库表ForeignKey。choices用于静态数据，如果有的话，变化不大。

注意

每次choices更改顺序时都会创建一个新的迁移。

除非blank=False在字段上设置， 否则将使用选择框呈现default包含的标签"---------"。要覆盖此行为，请将一个元组添加到choices 包含None; 例如。或者，您可以使用空字符串而不是有意义的字符串- 例如a 。(None, 'Your String ForDisplay')NoneCharField

db_column¶

Field. db_column ¶

用于此字段的数据库列的名称。如果没有给出，Django将使用该字段的名称。

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

db_index¶

Field. db_index ¶

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

db_tablespace¶

Field. db_tablespace ¶

如果此字段已编制索引，则用于此字段索引的数据库表空间的名称。默认值为项目的 DEFAULT_INDEX_TABLESPACE设置（如果已设置）或db_tablespace模型的设置（如果有）。如果后端不支持索引的表空间，则忽略此选项。

default¶

Field. default ¶

字段的默认值。这可以是值或可调用对象。如果可调用，则每次创建新对象时都会调用它。

默认不能是可变对象（模型实例，list，set等），作为该对象的相同实例的引用将被用作在所有新的模型实例的默认值。而是将所需的默认值包装在可调用的中。例如，如果要指定一个默认dict的 JSONField，使用函数：

def contact_default():
    return {"email": "to1@example.com"} contact_info = JSONField("ContactInfo", default=contact_default) 

lambdas不能用于字段选项，default因为它们无法通过迁移进行序列化。请参阅其他警告的文档。

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

创建新模型实例时，将使用默认值，并且不为该字段提供值。当字段是主键时，默认值也会在字段设置为时使用None。

editable¶

Field. editable ¶

如果False，该字段将不会显示在管理员或任何其他字段中 ModelForm。在模型验证期间也会跳过它们。默认是True。

error_messages¶

Field. error_messages ¶

该error_messages参数允许您覆盖该字段将引发的默认消息。传入一个字典，其中的键与您要覆盖的错误消息相匹配。

错误消息键包括null，blank，invalid，invalid_choice， unique，和unique_for_date。在下面的“ 字段类型”部分中为每个字段指定了其他错误消息密钥。

这些错误消息通常不会传播到表单。请参阅 有关模型的error_messages的注意事项。

help_text¶

Field. help_text ¶

使用表单小部件显示的额外“帮助”文本。即使您的字段未在表单上使用，它也对文档很有用。

请注意，此值不会在自动生成的表单中进行HTML转义。help_text如果您愿意，这可以让您包含HTML 。例如：

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

或者，您可以使用纯文本并 django.utils.html.escape()转义任何HTML特殊字符。确保您转义可能来自不受信任的用户的任何帮助文本，以避免跨站点脚本攻击。

primary_key¶

Field. primary_key ¶

如果True，此字段是模型的主键。

如果没有primary_key=True为模型中的任何字段指定，Django将自动添加一个AutoField来保存主键，因此primary_key=True除非要覆盖默认的主键行为，否则不需要设置任何字段。有关更多信息，请参阅 自动主键字段。

primary_key=True暗示null=False和 unique=True。对象上只允许一个主键。

主键字段是只读的。如果更改现有对象上的主键值，然后保存它，则将创建一个与旧对象并排的新对象。

unique¶

Field. unique ¶

如果True，该字段在整个表格中必须是唯一的。

这在数据库级别和模型验证中强制执行。如果您尝试在unique 字段中保存具有重复值的模型，django.db.IntegrityError则将通过模型的save()方法引发 a 。

此选项适用于除ManyToManyField和 之外的所有字段类型OneToOneField。

请注意，当unique是True，你并不需要指定 db_index，因为unique意味着索引的创建。

unique_for_date¶

Field. unique_for_date ¶

将其设置为a的名称DateField或DateTimeField要求此字段对于日期字段的值是唯一的。

举例来说，如果你有一个字段title有 unique_for_date="pub_date"，那么Django的不允许的两个记录具有相同的入口title和pub_date。

请注意，如果将其设置为指向a DateTimeField，则仅考虑该字段的日期部分。此外，当USE_TZ是 True时，支票将在执行当前时区的对象被保存的时间。

这Model.validate_unique()在模型验证期间强制执行，但在数据库级别不强制执行。如果任何unique_for_date约束涉及不属于a 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 ¶

要为此字段运行的验证程序列表。有关更多信息，请参阅验证器文档。

注册和获取查找¶

Field实现查找注册API。API可用于自定义哪些查找可用于字段类，以及如何从字段中获取查找。

字段类型¶

AutoField¶

class AutoField （ ** options ） [source]  ¶

一IntegerField，根据可用ID自动递增。您通常不需要直接使用它; 如果您没有另外指定，主键字段将自动添加到您的模型中。请参阅自动主键字段。

BigAutoField¶

class BigAutoField （ ** options ） [source]  ¶

一个64位整数，很像一个AutoField不同之处在于它是保证从适合数字1到9223372036854775807。

BigIntegerField¶

class BigIntegerField （ ** options ） [source]  ¶

一个64位整数，很像一个IntegerField不同之处在于它是保证从适合数字-9223372036854775808到 9223372036854775807。此字段的默认表单窗口小部件是a TextInput。

BinaryField¶

class BinaryField （ max_length = None ， ** options ） [来源]  ¶

用于存储原始二进制数据的字段。它可以分配bytes， bytearray或memoryview。

默认情况下，BinaryField设置editable为False，在这种情况下，它不能包含在a中ModelForm。

在Django 2.1中更改：

较旧的版本不允许设置editable为True。

BinaryField 有一个额外的可选参数：

BinaryField. max_length ¶

字段的最大长度（以字符为单位）。在Django的验证中强制使用最大长度 MaxLengthValidator。

滥用 BinaryField

虽然您可能会考虑将文件存储在数据库中，但请考虑在99％的情况下这是不好的设计。此字段是不是适当的替代静态文件处理。

BooleanField¶

class BooleanField （ ** options ） [source]  ¶

真/假字段。

此字段的默认表单窗口小部件是CheckboxInput，或者NullBooleanSelect是null=True。

默认值BooleanField是None当Field.default 没有定义。

在Django 2.1中更改：

在旧版本中，此字段不允许null=True，因此您必须使用NullBooleanField。现在不鼓励使用后者，因为它可能会在未来版本的Django中被弃用。

CharField¶

class CharField （ max_length = None ， ** options ） [来源]  ¶

字符串字段，用于小到大的字符串。

对于大量文本，请使用TextField。

此字段的默认表单窗口小部件是a TextInput。

CharField 有一个额外的必要参数：

CharField. max_length ¶

字段的最大长度（以字符为单位）。max_length在数据库级别和Django的验证中强制执行 MaxLengthValidator。

注意

如果您正在编写一个必须可移植到多个数据库后端的应用程序，您应该知道max_length某些后端存在限制 。有关详细信息，请参阅数据库后端说明。

DateField¶

class DateField （ auto_now = False ， auto_now_add = False ， **选项 ） [来源]  ¶

日期，由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()

此字段的默认表单窗口小部件是a 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选项将始终使用的日期默认时区在创建或更新的时刻。如果您需要不同的东西，您可能需要考虑简单地使用您自己的可调用默认值或覆盖save() 而不是使用auto_now或auto_now_add; 或者使用a DateTimeField而不是a 来DateField决定如何在显示时处理从datetime到date的转换。

DateTimeField¶

class DateTimeField （ auto_now = False ， auto_now_add = False ， **选项 ） [来源]  ¶

日期和时间，由Python datetime.datetime实例表示。采取相同的额外参数DateField。

此字段的默认表单窗口小部件是单个 TextInput。管理员使用两个单独的 TextInput小部件和JavaScript快捷方式。

DecimalField¶

类 DecimalField （ max_digits =无 ， decimal_places =无 ， **选项 ） [源]  ¶

一个固定精度的十进制数，由Python Decimal实例表示。它使用验证输入 DecimalValidator。

有两个必需的参数：

DecimalField. max_digits ¶

数字中允许的最大位数。请注意，此数字必须大于或等于decimal_places。

DecimalField. decimal_places ¶

与数字一起存储的小数位数。

例如，要存储999分辨率为2位小数的数字，您可以使用：

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

并存储大约10亿的数字，分辨率为10位小数：

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

此字段的默认表单控件是NumberInput 当localize为False或 TextInput以其他方式。

注意

有关FloatField和DecimalField类之间差异的更多信息 ，请参阅FloatField与DecimalField。

DurationField¶

class DurationField （ ** options ） [source]  ¶

用于存储时间段的字段 - 用Python建模 timedelta。在PostgreSQL上使用时，使用interval的数据类型是Oracle，数据类型是。否则使用一微秒。INTERVAL DAY(9) TO SECOND(6)bigint

注意

算术DurationField在大多数情况下都适用。但是在除PostgreSQL之外的所有数据库上，将a的值DurationField 与算术DateTimeField实例进行比较将无法按预期工作。

EmailField¶

class EmailField （ max_length = 254 ， ** options ） [来源]  ¶

一CharField，检查该值是使用一个有效的电子邮件地址 EmailValidator。

FileField¶

class FileField （ upload_to = None ， max_length = 100 ， ** options ） [source]  ¶

文件上传字段。

注意

该primary_key参数不受支持，如果使用则会引发错误。

有两个可选参数：

FileField. upload_to ¶

此属性提供了设置上载目录和文件名的方法，可以通过两种方式进行设置。在这两种情况下，该值都将传递给该 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，则字符串值将附加到MEDIA_ROOT路径中，以在本地文件系统上形成将存储上载文件的位置。如果您使用的是其他存储，请检查该存储的文档以了解其处理方式upload_to。

upload_to也可以是可调用的，例如函数。这将被调用以获取上载路径，包括文件名。这个callable必须接受两个参数并返回一个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 ¶

存储对象，用于处理文件的存储和检索。有关如何提供此对象的详细信息，请参阅管理文件。

此字段的默认表单窗口小部件是a ClearableFileInput。

在模型中使用a FileField或ImageField（见下文）需要几个步骤：

1. 在您的设置文件中，您需要定义MEDIA_ROOT为您希望Django存储上载文件的目录的完整路径。（为了提高性能，这些文件不会存储在数据库中。）定义 MEDIA_URL为该目录的基本公共URL。确保Web服务器的用户帐户可以写入此目录。
2. 将FileField或添加ImageField到模型中，定义upload_to用于指定MEDIA_ROOT用于上载文件的子目录的选项 。
3. 将存储在数据库中的所有内容都是文件的路径（相对于MEDIA_ROOT）。你很可能想要使用urlDjango提供的便利属性。例如，如果ImageField调用了 mug_shot您，则可以在模板中获取图像的绝对路径 。{{ object.mug_shot.url }}

例如，假设您MEDIA_ROOT设置为'/home/media'，并 upload_to设置为'photos/%Y/%m/%d'。所述'%Y/%m/%d' 的部分upload_to被strftime()格式化; '%Y'是四位数的年份，'%m'是两位数的月份，'%d'是两位数的一天。如果您在2007年1月15日上传文件，它将保存在目录中/home/media/photos/2007/01/15。

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

注意

该文件是作为将模型保存在数据库中的一部分保存的，因此在保存模型之前，不能依赖磁盘上使用的实际文件名。

可以使用该url属性获取上载文件的相对URL 。在内部，它调用url()底层Storage类的方法。

请注意，无论何时处理上传的文件，都应密切关注上传文件的位置以及文件的类型，以避免安全漏洞。验证所有上传的文件，以确保文件符合您的认可。例如，如果您盲目地让某人将文件上传到Web服务器文档根目录中的目录而无需验证，那么有人可以上传CGI或PHP脚本并通过访问您站点上的URL来执行该脚本。不要允许。

另请注意，即使是上传的HTML文件，因为它可以由浏览器执行（虽然不是由服务器执行），但可能会产生相当于XSS或CSRF攻击的安全威胁。

FileField实例在数据库中创建为varchar 默认最大长度为100个字符的列。与其他字段一样，您可以使用max_length参数更改最大长度。

FileField和FieldFile¶

class  FieldFile [source]  ¶

当您访问FileField模型时，您将获得一个FieldFile用于访问基础文件的代理实例。

FieldFile镜像的API File，有一个关键区别：由类包装的对象不一定是Python的内置文件对象的包装器。相反，它是Storage.open()方法结果的包装器，可以是File对象，也可以是自定义存储的FileAPI 实现。

除了从继承了API File诸如 read()和write()，FieldFile包括可用于与下面的文件交互的几种方法：

警告

这个类中，有两种方法save()，并 delete()，默认保存的相关模型对象FieldFile在数据库中。

FieldFile. name ¶

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

FieldFile. size ¶

基础Storage.size()方法的结果。

FieldFile. url ¶

一个只读属性，用于通过调用url()基础Storage类的方法 来访问文件的相对URL 。

FieldFile. open （ mode ='rb' ） [来源]  ¶

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

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

FieldFile. close （） [来源]  ¶

表现得像标准的Python file.close()方法，并关闭与此实例关联的文件。

FieldFile. save （ name ， content ， save = True ） [来源]  ¶

此方法获取文件名和文件内容，并将它们传递给该字段的存储类，然后将存储的文件与模型字段相关联。如果要手动将文件数据与FileField模型上的实例关联 ，则该save() 方法用于保留该文件数据。

采用两个必需的参数：name文件的名称，以及 content包含文件内容的对象。可选save参数控制是否在更改与此字段关联的文件后保存模型实例。默认为 True。

请注意，content参数应该是 django.core.files.FilePython的内置文件对象的实例。您可以File从现有的Python文件对象构造一个如下：

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

有关更多信息，请参阅管理文件。

FieldFile. delete （ save = True ） [来源]  ¶

删除与此实例关联的文件，并清除该字段上的所有属性。注意：如果文件在delete()调用时恰好打开，则此方法将关闭该文件 。

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

请注意，删除模型时，不会删除相关文件。如果您需要清理孤立的文件，您需要自己处理它（例如，使用可以手动运行或计划通过例如cron定期运行的自定义管理命令）。

FilePathField¶

class FilePathField （ path = None ， match = None ， recursive = False ， max_length = 100 ， ** options ） [source]  ¶

A 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适用于基本文件名，而不是完整路径。所以，这个例子：

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个字符的列。与其他字段一样，您可以使用max_length参数更改最大长度。

FloatField¶

class FloatField （ ** options ） [source]  ¶

由float实例在Python中表示的浮点数。

此字段的默认表单控件是NumberInput 当localize为False或 TextInput以其他方式。

FloatField 与 DecimalField

该FloatField班有时夹杂了 DecimalField阶级。虽然它们都代表实数，但它们以不同的方式表示这些数字。 内部FloatField使用Python的float类型，而DecimalField使用Python的Decimal类型。有关两者之间差异的信息，请参阅该decimal模块的Python文档。

ImageField¶

class ImageField （ upload_to = None ， height_field = None ， width_field = None ， max_length = 100 ， **选项 ） [source]  ¶

从中继承所有属性和方法FileField，但也验证上载的对象是有效图像。

除了可用于特殊属性FileField，一个ImageField也具有height和width属性。

为了便于查询这些属性，ImageField有两个额外的可选参数：

ImageField. height_field ¶

每次保存模型实例时，将使用图像高度自动填充的模型字段的名称。

ImageField. width_field ¶

每次保存模型实例时，将使用图像宽度自动填充的模型字段的名称。

需要枕头库。

ImageField实例在数据库中创建为varchar 默认最大长度为100个字符的列。与其他字段一样，您可以使用max_length参数更改最大长度。

此字段的默认表单窗口小部件是a ClearableFileInput。

IntegerField¶

class IntegerField （ ** options ） [source]  ¶

一个整数。从价值观-2147483648到2147483647在Django支持的所有数据库的安全。

它使用MinValueValidator并 MaxValueValidator根据默认数据库支持的值验证输入。

此字段的默认表单控件是NumberInput 当localize为False或 TextInput以其他方式。

GenericIPAddressField¶

class GenericIPAddressField （ protocol ='both' ， unpack_ipv4 = False ， ** options ） [source]  ¶

IPv4或IPv6地址，采用字符串格式（例如192.0.2.30或 2a02:42fe::4）。此字段的默认表单窗口小部件是a TextInput。

接下来是IPv6地址规范化 RFC 4291＃section-2.2第 2.2节，包括使用该节第3段中建议的IPv4格式，如 ::ffff:192.0.2.0。例如，2001:0::0:01将被标准化为 2001::1，并::ffff:0a0a:0a0a到::ffff:10.10.10.10。所有字符都转换为小写。

GenericIPAddressField. protocol ¶

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

GenericIPAddressField. unpack_ipv4 ¶

解压缩IPv4映射地址，如::ffff:192.0.2.1。如果启用此选项，则该地址将被解压缩到 192.0.2.1。默认为禁用。只能在protocol设置为时使用'both'。

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

NullBooleanField¶

class NullBooleanField （ ** options ） [source]  ¶

就像BooleanField用null=True。使用它代替此字段，因为它可能在Django的未来版本中被弃用。

PositiveIntegerField¶

class PositiveIntegerField （ ** options ） [source]  ¶

像一个IntegerField，但必须是正面或零（0）。从价值观0到2147483647在Django支持的所有数据库的安全。0出于向后兼容性原因，接受该值。

PositiveSmallIntegerField¶

class PositiveSmallIntegerField （ ** options ） [source]  ¶

像a PositiveIntegerField，但只允许某个（依赖于数据库）点下的值。从价值观0到32767在Django支持的所有数据库的安全。

SlugField¶

class SlugField （ max_length = 50 ， ** options ） [来源]  ¶

Slug是一个报纸术语。slu is是一种短标签，只包含字母，数字，下划线或连字符。它们通常用于URL。

与CharField类似，您可以指定max_length（阅读有关数据库可移植性的说明以及max_length该部分中的说明）。如果max_length未指定，Django将使用默认长度50。

意味着设置Field.db_index为True。

基于某个其他值的值自动预填充SlugField通常很有用。您可以在管理员中自动执行此操作 prepopulated_fields。

它用于validate_slug或 validate_unicode_slug用于验证。

SlugField. allow_unicode ¶

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

SmallIntegerField¶

class SmallIntegerField （ ** options ） [source]  ¶

像一个IntegerField，但只允许某个（数据库相关）点下的值。从价值观-32768到32767在Django支持的所有数据库的安全。

TextField¶

class TextField （ ** options ） [source]  ¶

一个大的文本字段。此字段的默认表单窗口小部件是a Textarea。

如果指定max_length属性，它将反映在Textarea自动生成的表单字段的 窗口小部件中。但是，它不会在模型或数据库级别强制执行。使用一个 CharField。

TimeField¶

class TimeField （ auto_now = False ， auto_now_add = False ， **选项 ） [来源]  ¶

一个时间，由Python datetime.time实例表示。接受相同的自动填充选项DateField。

此字段的默认表单窗口小部件是a TextInput。管理员添加了一些JavaScript快捷方式。

URLField¶

class URLField （ max_length = 200 ， ** options ） [来源]  ¶

A CharField的URL，经过验证 URLValidator。

此字段的默认表单窗口小部件是a TextInput。

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

UUIDField¶

class UUIDField （ ** options ） [source]  ¶

用于存储通用唯一标识符的字段。使用Python的 UUID类。在PostgreSQL上使用时，它以uuid数据类型存储，否则存储在 char(32)。

通用唯一标识符是AutoFieldfor的 一个很好的替代品primary_key。数据库不会为您生成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，而不是实例UUID。

关系字段¶

Django还定义了一组表示关系的字段。

ForeignKey¶

class ForeignKey （ to ， on_delete ， ** options ） [source]  ¶

多对一的关系。需要两个位置参数：与模型相关的类和on_delete选项。

要创建递归关系 - 与自身具有多对一关系的对象 - 使用。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：

产品/ models.py中¶

from django.db import models

class AbstractCar(models.Model): manufacturer = models.ForeignKey('Manufacturer', on_delete=models.CASCADE) class Meta: abstract = True 

生产/ 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, ) 

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

在数据库上自动创建数据库索引ForeignKey。您可以通过设置db_index为禁用此功能False。如果要为一致性而不是连接创建外键，或者如果要创建替代索引（如部分或多列索引），则可能希望避免索引的开销。

数据库表示¶

在幕后，Django追加"_id"字段名称来创建其数据库列名。在上面的示例中，Car 模型的数据库表将包含一manufacturer_id列。（您可以通过指定显式更改此内容db_column）但是，除非编写自定义SQL，否则您的代码永远不必处理数据库列名。您将始终处理模型对象的字段名称。

参数¶

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

ForeignKey. on_delete ¶

当ForeignKey删除a引用的对象时，Django将模拟on_delete参数指定的SQL约束的行为 。例如，如果您有一个可空的， ForeignKey并且希望在删除引用的对象时将其设置为null：

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

on_delete不会在数据库中创建SQL约束。稍后可以实现对数据库级级联选项的支持。

可能的值on_delete可在以下位置找到 django.db.models：

• CASCADE [来源]  ¶

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

  Model.delete()不会在相关模型上调用，但 会为所有已删除的对象发送pre_delete和 post_delete信号。

• PROTECT [来源]  ¶

  通过引发ProtectedError子类来 防止删除引用的对象 django.db.IntegrityError。

• SET_NULL [来源]  ¶

  设置ForeignKeynull; 这是如果只可能 null是True。

• SET_DEFAULT [来源]  ¶

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

• SET （） [来源]  ¶

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

• DO_NOTHING [来源]  ¶

  不采取行动。如果数据库后端强制实施参照完整性，则IntegrityError除非您手动将SQL 约束添加到数据库字段，否则将导致这种情况。ON DELETE

ForeignKey. limit_choices_to ¶

当使用a 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管理员中可能会有所帮助。

可调用的表单可能很有用，例如，当与Python datetime模块一起使用时，可以按日期范围限制选择。例如：

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

如果limit_choices_to是或返回，这是很有用复杂的查询，那么将只有当字段没有列在管理员可用的选项的效果 在 为模型。Qobjectraw_id_fieldsModelAdmin

注意

如果使用了callable limit_choices_to，则每次实例化新表单时都会调用它。也可以在验证模型时调用它，例如通过管理命令或管理员。admin构造查询集以多次在各种边缘情况下验证其表单输入，因此可能会多次调用您的可调用对象。

ForeignKey. related_name ¶

用于从相关对象返回到此关系的关系的名称。它也是related_query_name（用于目标模型的反向过滤器名称的名称）的默认值。有关完整说明和示例，请参阅相关对象文档。请注意，在抽象模型上定义关系时必须设置此值 ; 当你这样做时，可以使用 一些特殊的语法。

如果你喜欢的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通过一些特殊的语法支持app标签和类插值。

ForeignKey. to_field ¶

关系所涉及的相关对象上的字段。默认情况下，Django使用相关对象的主键。如果您引用其他字段，则该字段必须具有unique=True。

ForeignKey. db_constraint ¶

控制是否应在数据库中为此外键创建约束。默认是True，这几乎可以肯定你想要的; 将此设置False为非常糟糕的数据完整性。也就是说，这里有一些你可能想要这样做的场景：

• 您的遗留数据无效。
• 您正在分片数据库。

如果设置为False，则访问不存在的相关对象将引发其DoesNotExist异常。

ForeignKey. swappable ¶

如果ForeignKey 指向可交换模型，则控制迁移框架的反应。如果是True- 默认值 - 那么如果ForeignKey指向与当前值settings.AUTH_USER_MODEL（或另一个可交换模型设置）匹配的模型，则关系将使用对设置的引用存储在迁移中，而不是直接存储在模型中。

False如果您确定模型应始终指向交换模型，则只需要覆盖此项- 例如，如果它是专门为您的自定义用户模型设计的配置文件模型。

将其设置为False并不意味着您可以引用可交换模型，即使它已被换出 - False只是意味着使用此ForeignKey进行的迁移将始终引用您指定的确切模型（因此如果用户尝试使用例如，您不支持的用户模型。

如有疑问，请将其保留为默认值True。

ManyToManyField¶

class ManyToManyField （ to ， ** options ） [来源]  ¶

多对多的关系。需要一个位置参数：与模型相关的类，它与它的作用完全相同 ForeignKey，包括递归和 惰性关系。

可以使用字段添加，删除或创建相关对象 RelatedManager。

数据库表示¶

在幕后，Django创建了一个中间连接表来表示多对多关系。默认情况下，此表名称是使用多对多字段的名称以及包含它的模型的表名生成的。由于某些数据库不支持超过一定长度的表名，因此将自动截断这些表名，并使用唯一性哈希，例如author_books_9cdf。您可以使用该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。

limit_choices_to在使用参数ManyToManyField指定的自定义中间表上使用 时无效through。

ManyToManyField. symmetrical ¶

仅用于自我的ManyToManyFields定义。考虑以下模型：

from django.db import models

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

当Django处理这个模型时，它会识别它有一个 ManyToManyFieldon，因此它不会person_set向Person该类添加一个 属性。相反，ManyToManyField假设是对称的 - 也就是说，如果我是你的朋友，那么你就是我的朋友。

如果你不想在多对多关系中对称self，设置 symmetrical为False。这将迫使Django为反向关系添加描述符，允许ManyToManyField关系是非对称的。

ManyToManyField. through ¶

Django将自动生成一个表来管理多对多关系。但是，如果要手动指定中间表，可以使用该through选项指定表示要使用的中间表的Django模型。

此选项最常见的用途是，您希望将 额外数据与多对多关系相关联。

如果未指定显式through模型，则仍可使用隐式through模型类来直接访问为保存关联而创建的表。它有三个字段来链接模型。

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

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

如果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有两个外键Person（person和 inviter），这使得关系模糊不清，Django无法知道使用哪一个。在这种情况下，您必须明确指定Django应使用哪些外键through_fields，如上例所示。

through_fields接受一个2元组，其中 是定义的模型的外键名称 （在本例中），以及 目标模型的外键名称（ 在本例中）。('field1', 'field2')field1ManyToManyFieldgroupfield2person

如果中间模型上有多个外键到参与多对多关系的任何（甚至两个）模型，则必须指定through_fields。这也适用于 使用中间模型时的递归关系，并且模型有两个以上的外键，或者您想要明确指定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（或另一个可交换模型设置）匹配的模型，则关系将使用对设置的引用存储在迁移中，而不是直接存储在模型中。

False如果您确定模型应始终指向交换模型，则只需要覆盖此项- 例如，如果它是专门为您的自定义用户模型设计的配置文件模型。

如有疑问，请将其保留为默认值True。

ManyToManyField不支持validators。

null 因为没有办法在数据库级别要求关系，所以没有任何效果。

OneToOneField¶

class OneToOneField （ to ， on_delete ， parent_link = False ， ** options ） [source]  ¶

一对一的关系。从概念上讲，这类似于 ForeignKeywith unique=True，但关系的“反向”方面将直接返回单个对象。

这作为模型的主键是最有用的，它以某种方式“扩展”另一个模型; 例如，通过从子模型向父模型添加隐式一对一关系来实现多表继承。

需要一个位置参数：与模型相关的类。这与它的工作方式完全相同ForeignKey，包括有关递归 和惰性关系的所有选项。

如果没有related_name为其指定参数 OneToOneField，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，加上一个额外的参数：

OneToOneField. parent_link ¶

在True继承自另一个 具体模型的模型中使用时，表示该字段应该用作返回父类的链接，而不是OneToOneField通常由子类隐式创建的额外字段 。

有关使用示例，请参阅一对一关系OneToOneField。

Field API参考¶

class  Field [source]  ¶

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

因此，字段是不同Django API中的基础部分，特别是 models和querysets。

在模型中，字段被实例化为类属性并表示特定的表列，请参阅模型。它具有Django用于将字段值映射到特定于数据库的值的属性，例如null和unique，以及方法。

阿Field是的一个子类 RegisterLookupMixin，因此两者 Transform并 Lookup可以登记在其上中使用QuerySetS（例如field_name__exact="foo"）。默认情况下会注册所有内置查找。

所有Django的内置字段，例如CharField，都是特定的实现Field。如果您需要自定义字段，则可以子类化任何内置字段或Field从头开始编写。无论是哪种情况，请参阅编写自定义模型字段。

description ¶

该字段的详细描述，例如 django.contrib.admindocs应用程序。

描述可以是以下形式：

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

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

为了将数据映射Field到特定于数据库的类型，Django公开了几种方法：

get_internal_type （） [来源]  ¶

返回一个字符串，为后端特定目的命名此字段。默认情况下，它返回类名。

请参阅模拟内置字段类型以在自定义字段中使用。

db_type （ 连接 ） [来源]  ¶

返回数据库列数据类型Field，考虑到connection。

请参阅自定义数据库类型以了解自定义字段

rel_db_type （ 连接 ） [来源]  ¶

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

请参阅自定义数据库类型以了解自定义字段

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

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

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

get_prep_value （ 值 ） [来源]  ¶

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

请参阅转换Python对象以查询使用值。

get_db_prep_value （ 值 ， 连接 ， 准备=假 ） [来源]  ¶

转换value为特定于后端的值。默认情况下，它返回 valueif prepared=True和get_prep_value()if False。

请参阅将查询值转换为数据库值以供使用。

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

from_db_value （ 值 ， 表达 ， 连接 ） ¶

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

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

请参阅将值转换为Python对象以供使用。

注意

出于性能原因，from_db_value没有在不需要它的字段上实现no-op（所有Django字段）。因此，您可能不会super在您的定义中提及。

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

get_db_prep_save （ 值 ， 连接 ） [来源]  ¶

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

pre_save （ model_instance ， add ） [来源]  ¶

get_db_prep_save()在保存之前调用值之前调用的方法（例如for DateField.auto_now）。

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

它应该返回model_instance此字段的相应属性的值 。属性名称在 self.attname（由此设置Field）。

请参阅保存以供使用前预处理值。

字段通常从序列化或表单中将其值作为不同类型接收。

to_python （ 值 ） [来源]  ¶

将值转换为正确的Python对象。它起反作用value_to_string()，也称为 反转clean()。

请参阅将值转换为Python对象以供使用。

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

value_from_object （ obj ） [来源]  ¶

返回给定模型实例的字段值。

这种方法经常被使用value_to_string()。

value_to_string （ obj ） [来源]  ¶

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

请参阅转换字段数据以进行序列化以便使用。

使用时， 需要知道应该表示哪个表单字段：model formsField

formfield （ form_class = None ， choices_form_class = None ， ** kwargs ） [来源]  ¶

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

默认情况下，如果同时form_class和choices_form_class是 None，它使用CharField。如果字段 choices并choices_form_class 没有指定，它使用TypedChoiceField。

请参阅为模型字段指定表单字段以供使用。

deconstruct （） [来源]  ¶

返回一个包含足够信息的4元组来重新创建字段：

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

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

字段属性引用¶

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

字段的属性¶

Field. auto_created ¶

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

Field. concrete ¶

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

Field. hidden ¶

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

注意

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

Field. is_relation ¶

布尔标志，表明如果一个字段包含一个或多个其他模型的功能（例如引用ForeignKey， ManyToManyField，OneToOneField，等）。

Field. model ¶

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

具有关系的字段的属性¶

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

Field. many_to_many ¶

布尔标志，True如果该字段具有多对多关系; False除此以外。唯一的领域包括Django的地方，这是 True是ManyToManyField。

Field. many_to_one ¶

布尔标志，True如果该字段具有多对一关系，例如a ForeignKey; False除此以外。

Field. one_to_many ¶

布尔标志，True如果该字段具有一对多关系，例如a GenericRelation或反向a ForeignKey; False 除此以外。

Field. one_to_one ¶

布尔标志，True如果该字段具有一对一的关系，例如a OneToOneField; False除此以外。

Field. related_model ¶

指向该领域涉及的模型。例如，Author在 。在一个始终。ForeignKey(Author,on_delete=models.CASCADE)related_modelGenericForeignKeyNone

转载于:https://www.cnblogs.com/grimm/p/11124593.html