Django模型(1)

2020-04-23 本文已影响0人成长之路丶

1. ORM模型介绍

随着项目越来越大，采用写原生SQL的方式在代码中会出现大量的SQL语句，那么问题就出现了：

SQL语句重复利用率不高，越复杂的SQL语句条件越多，代码越长。会出现很多相近的SQL语句。
很多SQL语句是在业务逻辑中拼出来的，如果有数据库需要更改，就要去修改这些逻辑，这会很容易漏掉对某些SQL语句的修改。
写SQL时容易忽略web安全问题，给未来造成隐患。SQL注入。

ORM，全称Object Relational Mapping，中文叫做对象关系映射，通过ORM我们可以通过类的方式去操作数据库，而不用再写原生的SQL语句。通过把表映射成类，把行作实例，把字段作为属性，ORM在执行对象操作的时候最终还是会把对应的操作转换为数据库原生语句。使用ORM有许多优点：

易用性：使用ORM做数据库的开发可以有效的减少重复SQL语句的概率，写出来的模型也更加直观、清晰。
性能损耗小：ORM转换成底层数据库操作指令确实会有一些开销。但从实际的情况来看，这种性能损耗很少（不足5%），只要不是对性能有严苛的要求，综合考虑开发效率、代码的阅读性，带来的好处要远远大于性能损耗，而且项目越大作用越明显。
设计灵活：可以轻松的写出复杂的查询。
可移植性：Django封装了底层的数据库实现，支持多个关系数据库引擎，包括流行的MySQL、PostgreSQL和SQLite。可以非常轻松的切换数据库。

2. 数据库的相关配置

Django数据库的相关配置在settings.py文件中的DATABASE进行设置。Django默认使用SQLite数据库可以不用配置（创建项目时已经配置好），如果需要使用其他数据库则需要指定数据库的类型（ENGINE）,然后根据选择的数据库类型配置其所需的其他参数选项。

# 默认数据库配置
DATABASES = {
    'default': {
        # 使用sqlite3数据库
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

# 配置mysql数据库配置
DATABASES = {
    'default': {
        # 数据库引擎（是mysql还是oracle等）
        'ENGINE': 'django.db.backends.mysql',
        # 数据库的名字
        'NAME': 'mytest',
        # 连接mysql数据库的用户名
        'USER': 'root',
        # 连接mysql数据库的密码
        'PASSWORD': 'root',
        # mysql数据库的主机地址
        'HOST': '127.0.0.1',
        # mysql数据库的端口号
        'PORT': '3306',
    }
}

ENGINE：数据库引擎，指定Django使用的数据库类型，Django支持PostgreSQL、MySQL、SQLite、 MariaDB 、Oracle等数据库，具体可以查看官方文档

3. 数据库模型的定义

ORM模型一般都是放在app的models.py文件中，每个模型都是一个继承至 django.db.models.Model 的python类，模型的每个属性表示一个数据库字段。

from django.db import models

# 定义一个myapp_person表，表名没有特别指定默认使用[app名称_模型类名小写]的方式定义
class Person(models.Model):
    # 如果没有定义主键，模型类会自动在数据库创建一个id字段，id字段是int类型自动增长并设置为主键
    # 定义一个user_name的字段，映射到数据库类型时varchar类型，最大长度为30
    user_name = models.CharField(max_length=30)
    # 定义一个user_age的字段，映射到数据库类型时int类型
    user_age = models.IntField()

3.1 模型类字段的类型

3.1.1 内置的字段类型

Django模型类字段的类型在 django.db.models.fields可以查看所有的字段类型及其实现源码，也可以在官方文档中查看，Django模型类字段类型大概有30个左右，这里只例举常见的字段类型：

AutoField：映射到数据库中是int类型，可以有自动增长的特性。一般不需要使用这个类型，如果不指定主键，那么模型会自动的生成一个叫做id的自动增长的主键。如果你想指定一个其他名字的并且具有自动增长的主键，使用AutoField也是可以的。
BigAutoField：64位的整形，类似于AutoField，只不过是产生的数据的范围是从1-9223372036854775807。
BooleanField：在模型层面接收的是True/False。在数据库层面是tinyint类型。如果没有指定默认值，默认值是None。
CharField：在数据库层面是varchar类型。在Python层面就是普通的字符串。这个类型在使用的时候必须要指定最大的长度，也即必须要传递max_length这个关键字参数进去。
DateField：日期类型。在Python中是datetime.date类型，可以记录年月日。在映射到数据库中也是date类型。使用这个Field可以传递以下几个参数：

(1). auto_now：在每次这个数据保存的时候，都使用当前的时间。比如作为一个记录修改日期的字段，可以将这个属性设置为True。

(2). auto_now_add：在每次数据第一次被添加进去的时候，都使用当前的时间。比如作为一个记录第一次入库的字段，可以将这个属性设置为True。
DateTimeField：日期时间类型，类似于DateField。不仅仅可以存储日期，还可以存储时间。映射到数据库中是datetime类型。这个Field也可以使用auto_now和auto_now_add两个属性。
TimeField：时间类型。在数据库中是time类型。在Python中是datetime.time类型。
EmailField：类似于CharField。在数据库底层也是一个varchar类型。最大长度是254个字符。
FileField：用来存储文件的。这个请参考后面的文件上传章节部分。
ImageField：用来存储图片文件的。这个请参考后面的图片上传章节部分。
FloatField：浮点类型。映射到数据库中是float类型。
IntegerField：整形。值的区间是-2147483648——2147483647。
BigIntegerField：大整形。值的区间是-9223372036854775808——9223372036854775807
PositiveIntegerField：正整形。值的区间是0——2147483647。
SmallIntegerField：小整形。值的区间是-32768——32767。
PositiveSmallIntegerField：正小整形。值的区间是0——32767。
TextField：大量的文本类型。映射到数据库中是longtext类型。
UUIDField：只能存储uuid格式的字符串。uuid是一个32位的全球唯一的字符串，一般用来作为主键。
URLField：类似于CharField，只不过只能用来存储url格式的字符串。并且默认的max_length是200。

3.1.2 自定义字段类型

有时Django内置的字段类型无法满足你的精确要求，或者你希望使用与Django附带的字段类型完全不同的字段类型，Django支持用户自定义字段类型。

自定义字段类型：定义一个类，这个类需继承至Field类（django.db.models.Field）或者Field类的子类，如：CharField、IntegerField类等

from django.db import models

class HandField(models.Field):

    description = "帮助卡牌分类，专门设置的类型"

    def __init__(self, *args, **kwargs):
        kwargs['max_length'] = 104
        super().__init__(*args, **kwargs)

所谓的自定义字段类型其实就是类的继承（继承内置的字段类型），在内置的字段类型基础之上扩展其他功能特性，因为自定义字段类型继承至Field类或其子类，所以自定义类的__init__()方法支持内置类型所有的字段可选参数[见3.2模型类字段可选参数]

如果需要在继承的字段上添加额外的选项，则需编写新的 deconstruct() 方法。deconstruct()方法很简单，它返回由四个项组成的元组：字段的属性名、字段类的完整导入路径、位置参数（作为列表）和关键字参数（作为dict）。

from django.db import models

class CommaSepField(models.Field):
    "实现列表的逗号分隔存储"

    def __init__(self, separator=",", *args, **kwargs):
        self.separator = separator
        super().__init__(*args, **kwargs)

    def deconstruct(self):
        name, path, args, kwargs = super().deconstruct()
        # 如果不是默认值，则仅包含kwarg
        if self.separator != ",":
            kwargs['separator'] = self.separator
        return name, path, args, kwargs

一当你自定义好了你的字段类型，你就可以像内置字段类型一样在models.py文件中使用它了。

class Person(models.Model):
    name = models.CharField(max_length=80)
    something_else = MytypeField()

如何自定义字段类型更加深入的用法请查看Django官方文档。

3.2 模型类字段可选参数

Django模型类字段除了可选择字段类型，还可以给字段增加一些限定参数，以下常用参数可用于所有字段类型。所有都是可选的，全部可选参数见官方文档，特定的模型类字段类型还有特定的可选参数，如CharField的max_length参数，但是在其他字段类型却不一定能使用。

null：如果设置为True，Django将会在映射表的时候指定是否为空。默认是为False。在使用字符串相关的Field（CharField/TextField）的时候，官方推荐尽量不要使用这个参数，也就是保持默认值False。因为Django在处理字符串相关的Field的时候，即使这个Field的null=False，如果你没有给这个Field传递任何值，那么Django也会使用一个空的字符串""来作为默认值存储进去。因此如果再使用null=True，Django会产生两种空值的情形（NULL或者空字符串）。如果想要在表单验证的时候允许这个字符串为空，那么建议使用blank=True。如果你的Field是BooleanField，那么对应的可空的字段则为NullBooleanField。

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

注意：null纯粹与数据库相关，而blank是否与验证相关。如果字段有blank=True，表单验证将允许输入空值。如果字段有blank=False，字段将是必需的。

db_column：用于此字段的数据库列的名称。如果没有给出，Django将使用模型类的属性作为数据库字段的名称。如果你的数据库列名是SQL保留字，或者包含在python变量名中不允许使用的字符（尤其是连字符），那么就可以使用这个参数。Django会在后台引用列和表名。

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

default：字段的默认值。这可以是一个值或可调用对象。如果可调用，则每次创建新对象时都会调用它，此外lambda 不能用于字段的default选项。默认值不能是可变对象（模型实例， list ， set 等），作为对该对象同一实例的引用，如果设置了default所有新模型实例在没有指定值时都会使用此默认值。当然也可以将所需的默认值包装在可调用文件中。

primary_key：如果 True ，此字段是模型的主键，默认是False 。如果您不指定 primary_key=True 对于模型中的任何字段，Django将自动添加一个字段名为id类型为AutoField保留主键，这样意味着定义模型类可以不需要设置 primary_key=True 在任何字段上，模型就有一个主键，除非要重写默认的主键行为才需要手动设置primary_key=True 在响应的字段上。 primary_key=True 暗示这字段 null=False（不能为空）和 unique=True（必须唯一），一个对象上只允许有一个主键。

unique：如果 True ，此字段在整个表中必须是唯一的。

validators：给字段指定特定的验证器，根据验证器来约束字段。

from django.core.exceptions import ValidationError
from django.utils.translation import gettext_lazy as _

# 只允许偶数的验证器
def validate_even(value):
    if value % 2 != 0:
        raise ValidationError(
            _('%(value)不是一个偶数！'),
            params={'value': value},
        )

可以通过字段的validators约束字段：

from django.db import models

class MyModel(models.Model):
    # 使用验证器约束字段
    even_field = models.IntegerField(validators=[validate_even])

注意：

有些可选参数有默认值，我们可以不用进行相关配置，除非需要对其默认值进行修改
有些参数是相互影响的，比如primary_key=True 暗示字段 null=False（不能为空）和 unique=True（必须唯一）

3.3 模型类的继承

类同于Python的类继承，Django也有完善的继承机制。Django中所有的模型类都必须继承django.db.models.Model， Django模型类之间有三种继承的方式：

抽象基类：被用来继承的模型被称为Abstract base classes，将子类共同的数据抽离出来，供子类继承重用，它不会创建实际的数据表；
多表继承：Multi-table inheritance，每一个模型都有自己的数据库表；
代理模型：如果你只想修改模型的Python层面的行为，并不想改动模型的字段，可以使用代理模型。

3.3.1 抽象基类

只需要在模型的Meta类里添加abstract=True元数据项，就可以将一个模型转换为抽象基类。Django不会为这种类创建实际的数据库表，它们也没有管理器，不能被实例化也无法直接保存，它们就是用来被继承的。抽象基类完全就是用来保存子模型们共有的内容部分，达到重用的目的。当它们被继承时，它们的字段会全部复制到子模型中。看下面的例子：

from django.db import models

class CommonInfo(models.Model):
    name = models.CharField(max_length=100)
    age = models.PositiveIntegerField()

    class Meta:
        abstract = True

class Student(CommonInfo):
    home_group = models.CharField(max_length=5)

Student模型将拥有name，age，home_group三个字段，并且CommonInfo模型不能当做一个正常的模型使用。

抽象基类的Meta数据：

如果子类没有声明自己的Meta类，那么它将继承抽象基类的Meta类。子类想扩展父类的 Meta类，可以将其子类化，下面的例子则扩展了基类的Meta：

from django.db import models

class CommonInfo(models.Model):
    # ...
    class Meta:
        abstract = True
        ordering = ['name']

class Student(CommonInfo):
    # ...
    class Meta(CommonInfo.Meta):
        db_table = 'student_info'

这里有几点要特别说明：

抽象基类中有的元数据，子模型没有的话，直接继承；
抽象基类中有的元数据，子模型也有的话，直接覆盖；
子模型可以额外添加元数据；
抽象基类中的abstract=True这个元数据不会被继承。也就是说如果想让一个抽象基类的子模型，同样成为一个抽象基类，那你必须显式的在该子模型的Meta中同样声明一个abstract = True；
有一些元数据对抽象基类无效，比如db_table，首先是抽象基类本身不会创建数据表，其次它的所有子类也不会按照这个元数据来设置表名。

注意related_name和related_query_name参数

如果在你的抽象基类中存在ForeignKey或者ManyToManyField字段，并且使用了related_name或者related_query_name参数，那么一定要小心了。因为按照默认规则，每一个子类都将拥有同样的字段，这显然会导致错误。为了解决这个问题，当你在抽象基类中使用related_name或者related_query_name参数时，它们两者的值中应该包含%(app_label)s和%(class)s部分：

%(class)s用字段所属子类的小写名替换
%(app_label)s用子类所属app的小写名替换

例如，对于common/models.py模块：

from django.db import models

class Base(models.Model):
    m2m = models.ManyToManyField(
    OtherModel,
    related_name="%(app_label)s_%(class)s_related",
    related_query_name="%(app_label)s_%(class)ss",
    )

    class Meta:
        abstract = True

class ChildA(Base):
    pass

class ChildB(Base):
    pass

对于另外一个应用中的rare/models.py:

from common.models import Base

class ChildB(Base):
    pass

对于上面的继承关系：

common.ChildA.m2m字段的reverse name（反向关系名）应该是common_childa_related；reverse query name(反向查询名)应该是common_childas。
common.ChildB.m2m字段的反向关系名应该是common_childb_related；反向查询名应该是common_childbs。
rare.ChildB.m2m字段的反向关系名应该是rare_childb_related；反向查询名应该是rare_childbs。

当然，如果你不设置related_name或者related_query_name参数，这些问题就不存在了。

3.3.2 多表继承

这种继承方式下，父类和子类都是独立自主、功能完整、可正常使用的模型，都有自己的数据库表，内部隐含了一个一对一的关系。例如：

from django.db import models

class Place(models.Model):
    name = models.CharField(max_length=50)
    address = models.CharField(max_length=80)

class Restaurant(Place):
    serves_hot_dogs = models.BooleanField(default=False)
    serves_pizza = models.BooleanField(default=False)

Restaurant将包含Place的所有字段，并且各有各的数据库表和字段，比如：

>>> Place.objects.filter(name="Bob's Cafe")
>>> Restaurant.objects.filter(name="Bob's Cafe")

如果一个Place对象同时也是一个Restaurant对象，你可以使用小写的子类名，在父类中访问它，例如：

>>> p = Place.objects.get(id=12)
# 如果p也是一个Restaurant对象，那么下面的调用可以获得该Restaurant对象。
>>> p.restaurant
<Restaurant: ...>

但是，如果这个Place是个纯粹的Place对象，并不是一个Restaurant对象，那么上面的调用方式会弹出Restaurant.DoesNotExist异常。

自动创建的 OneToOneField 在 Restaurant 链接到 Place 如下所示：

place_ptr = models.OneToOneField(
    Place, on_delete=models.CASCADE,
    parent_link=True,
)

可以通过创建一个OneToOneField字段并设置 parent_link=True，自定义这个一对一字段。

Meta和多表继承

在多表继承的情况下，由于父类和子类都在数据库内有物理存在的表，父类的Meta类会对子类造成不确定的影响，因此，Django在这种情况下关闭了子类继承父类的Meta功能。这一点和抽象基类的继承方式有所不同。

但是，还有两个Meta元数据特殊一点，那就是ordering和get_latest_by，这两个参数是会被继承的。因此，如果在多表继承中，你不想让你的子类继承父类的上面两种参数，就必须在子类中显示的指出或重写。如下：

class ChildModel(ParentModel):
    # ...

    class Meta:
        # 移除父类对子类的排序影响
        ordering = []

多表继承和反向关联

因为多表继承使用了一个隐含的OneToOneField来链接子类与父类，所以象上例那样，你可以从父类访问子类。但是这个OnetoOneField字段默认的related_name值与ForeignKey和 ManyToManyField默认的反向名称相同。如果你与父类或另一个子类做多对一或是多对多关系，你就必须在每个多对一和多对多字段上强制指定related_name。如果你没这么做，Django就会在你运行或验证(validation)时抛出异常。

仍以上面Place类为例，我们创建一个带有ManyToManyField字段的子类：

class Supplier(Place):
    customers = models.ManyToManyField(Place)

这会产生下面的错误：

Reverse query name for 'Supplier.customers' clashes with reverse query
name for 'Supplier.place_ptr'.
HINT: Add or change a related_name argument to the definition for
'Supplier.customers' or 'Supplier.place_ptr'.

解决方法是：向customers字段中添加related_name参数.

customers = models.ManyToManyField(Place, related_name='provider')。

3.3.3 代理模型

使用多表继承时，父类的每个子类都会创建一张新数据表，通常情况下，这是我们想要的操作，因为子类需要一个空间来存储不包含在父类中的数据。但有时，你可能只想更改模型在Python层面的行为，比如更改默认的manager管理器，或者添加一个新方法。

代理模型就是为此而生的。你可以创建、删除、更新代理模型的实例，并且所有的数据都可以像使用原始模型（非代理类模型）一样被保存。不同之处在于你可以在代理模型中改变默认的排序方式和默认的manager管理器等等，而不会对原始模型产生影响。

声明一个代理模型只需要将Meta中proxy的值设为True。

例如你想给Person模型添加一个方法。你可以这样做：

from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)

class MyPerson(Person):
    class Meta:
        proxy = True

    def do_something(self):
        # ...
        pass

MyPerson类将操作和Person类同一张数据库表。并且任何新的Person实例都可以通过MyPerson类进行访问，反之亦然。

>>> p = Person.objects.create(first_name="foobar")
>>> MyPerson.objects.get(first_name="foobar")
<MyPerson: foobar>

下面的例子通过代理进行排序，但父类却不排序：

class OrderedPerson(Person):
    class Meta:
        # 现在，普通的Person查询是无序的，而OrderedPerson查询会按照`last_name`排序。
        ordering = ["last_name"]
        proxy = True

一些约束：

代理模型必须继承自一个非抽象的基类，并且不能同时继承多个非抽象基类；
代理模型可以同时继承任意多个抽象基类，前提是这些抽象基类没有定义任何模型字段。
代理模型可以同时继承多个别的代理模型，前提是这些代理模型继承同一个非抽象基类。（早期Django版本不支持这一条）

代理模型的管理器

如不指定，则继承父类的管理器。如果你自己定义了管理器，那它就会成为默认管理器，但是父类的管理器依然有效。如下例子：

from django.db import models

class NewManager(models.Manager):
    # ...
    pass

class MyPerson(Person):
    objects = NewManager()

    class Meta:
        proxy = True

如果你想要向代理中添加新的管理器，而不是替换现有的默认管理器，你可以创建一个含有新的管理器的基类，并在继承时把他放在主基类的后面：

# Create an abstract class for the new manager.
class ExtraManagers(models.Model):
    secondary = NewManager()

    class Meta:
        abstract = True

class MyPerson(Person, ExtraManagers):
    class Meta:
        proxy = True

3.3.4 多重继承

注意，多重继承和多表继承是两码事，两个概念。

Django的模型体系支持多重继承，就像Python一样。如果多个父类都含有Meta类，则只有第一个父类的会被使用，剩下的会忽略掉。

一般情况，能不要多重继承就不要，尽量让继承关系简单和直接，避免不必要的混乱和复杂。

请注意，继承同时含有相同id主键字段的类将抛出异常。为了解决这个问题，你可以在基类模型中显式的使用AutoField字段。如下例所示：

class Article(models.Model):
    article_id = models.AutoField(primary_key=True)
    ...

class Book(models.Model):
    book_id = models.AutoField(primary_key=True)
    ...

class BookReview(Book, Article):
    pass

或者使用一个共同的祖先来持有AutoField字段，并在直接的父类里通过一个OneToOne字段保持与祖先的关系，如下所示：

class Piece(models.Model):
    pass

class Article(Piece):
    article_piece = models.OneToOneField(Piece, on_delete=models.CASCADE, parent_link=True)
    ...

class Book(Piece):
    book_piece = models.OneToOneField(Piece, on_delete=models.CASCADE, parent_link=True)
    ...

class BookReview(Book, Article):
    pass

警告

在Python语言层面，子类可以拥有和父类相同的属性名，这样会造成覆盖现象。但是对于Django，如果继承的是一个非抽象基类，那么子类与父类之间不可以有相同的字段名！

比如下面是不行的！

class A(models.Model):
    name = models.CharField(max_length=30)

class B(A):
    name = models.CharField(max_length=30)

如果你执行python manage.py makemigrations会弹出下面的错误：

django.core.exceptions.FieldError: Local field 'name' in class 'B' clashes with field of the same name from base class 'A'.

但是！如果父类是个抽象基类就没有问题了，如下：

class A(models.Model):
    name = models.CharField(max_length=30)

    class Meta:
        abstract = True

class B(A):
    name = models.CharField(max_length=30)

3.4 外键与表关系

3.4.1 外键

大部分关系型数据库都支持外键，以MySQL为例，在MySQL中，表有两种引擎，一种是InnoDB，另外一种是myisam。如果使用的是InnoDB引擎，是支持外键约束的。外键的存在使得ORM框架在处理表关系的时候异常的强大。

3.4.2 模型类中外键的定义

外键的类定义格式为class ForeignKey(to,on_delete,**options)。第一个参数是引用的是哪个模型，第二个参数是在使用外键引用的模型数据被删除了，这个字段该如何处理，有CASCADE、SET_NULL等处理方式。

实际案例：有一个User和一个Article两个模型。一个User可以发表多篇文章，一个Article只能有一个Author，并且通过外键进行引用。那么相关的示例代码如下：

class User(models.Model):
    username = models.CharField(max_length=20)
    password = models.CharField(max_length=100)


class Article(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()

    author = models.ForeignKey("User",on_delete=models.CASCADE)

以上使用ForeignKey来定义模型之间的关系。即在article的实例中可以通过author属性来操作对应的User模型。这样使用起来非常的方便。

使用了ForeignKey后，Django为Article表添加了一个属性名_id的字段（比如author的字段名称是author_id），这个字段是一个外键，记录着对应的作者（User模型）的主键。

如果想要引用另外一个app的模型，那么应该在传递to参数的时候，使用app.model_name进行指定。以上例为例，如果User和Article不是在同一个app中，那么在引用的时候的示例代码如下：

# User模型在user这个app中
class User(models.Model):
    username = models.CharField(max_length=20)
    password = models.CharField(max_length=100)

# Article模型在article这个app中
class Article(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()

    author = models.ForeignKey("user.User",on_delete=models.CASCADE)

如果模型的外键引用的是本身自己这个模型，那么to参数可以为'self'，或者是这个模型的名字。在论坛开发中，一般评论都可以进行二级评论，即可以针对另外一个评论进行评论，那么在定义模型的时候就需要使用外键来引用自身。示例代码如下：

class Comment(models.Model):
    content = models.TextField()
    origin_comment = models.ForeignKey('self',on_delete=models.CASCADE,null=True)
    # 或者
    # origin_comment = models.ForeignKey('Comment',on_delete=models.CASCADE,null=True)

limit_choices_to参数用于限制外键所能关联的对象，只能用于Django的ModelForm（Django的表单模块）和admin后台，对其它场合无限制功能。其值可以是一个字典、Q对象或者一个返回字典或Q对象的函数调用，如下例所示：

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

这样定义，则ModelForm的staff_member字段列表中，只会出现那些is_staff=True的Users对象，这一功能对于admin后台非常有用。

3.4.3 外键删除操作

如果一个模型使用了外键。那么在对方那个模型被删掉后，该进行什么样的操作。可以通过on_delete来指定。可以指定的类型如下：

CASCADE：级联操作。如果外键对应的那条数据被删除了，那么这条数据也会被删除。
PROTECT：受保护。即只要这条数据引用了外键的那条数据，那么就不能删除外键的那条数据。
SET_NULL：设置为空。如果外键的那条数据被删除了，那么在本条数据上就将这个字段设置为空。如果设置这个选项，前提是要指定这个字段可以为空。
SET_DEFAULT：设置默认值。如果外键的那条数据被删除了，那么本条数据上就将这个字段设置为默认值。如果设置这个选项，前提是要指定这个字段一个默认值。
SET()：如果外键的那条数据被删除了。那么将会获取SET函数中的值来作为这个外键的值。SET函数可以接收一个可以调用的对象（比如函数或者方法），如果是可以调用的对象，那么会将这个对象调用后的结果作为值返回回去。
DO_NOTHING：不采取任何行为。一切全看数据库级别的约束。

以上这些选项只是Django级别的，数据级别依旧是RESTRICT！

3.4.5 一对多

一对多或者多对一，都是通过ForeignKey来实现的，外键需要两个位置参数，一个是关联的模型，另一个是on_delete选项。外键要定义在多的一方！举个例子比如文章和作者之间的关系。一个文章只能由一个作者编写，但是一个作者可以写多篇文章。文章和作者之间的关系就是典型的多对一的关系。

 class User(models.Model):
     username = models.CharField(max_length=20)
     password = models.CharField(max_length=100)

 class Article(models.Model):
     title = models.CharField(max_length=100)
     content = models.TextField()
     author = models.ForeignKey("User",on_delete=models.CASCADE)

那么以后在给Article对象指定author，就可以使用以下代码来完成：

article = Article(title='abc',content='123')
author = User(username='zhiliao',password='111111')
# 要先保存到数据库中
author.save()
article.author = author
article.save()

并且以后如果想要获取某个用户下所有的文章，可以通过article_set来实现。示例代码如下：

user = User.objects.first()
# 获取第一个用户写的所有文章
articles = user.article_set.all()
for article in articles:
    print(article)

3.4.6 一对一

Django为一对一提供了一个专门的Field叫做OneToOneField来实现一对一操作。举个例子比如一个用户表和一个用户信息表。在实际网站中，可能需要保存用户的许多信息，但是有些信息是不经常用的。如果把所有信息都存放到一张表中可能会影响查询效率，因此可以把用户的一些不常用的信息存放到另外一张表中我们叫做UserExtension。但是用户表User和用户信息表UserExtension就是典型的一对一了。

 class User(models.Model):
     username = models.CharField(max_length=20)
     password = models.CharField(max_length=100)

 class UserExtension(models.Model):  
     birthday = models.DateTimeField(null=True)  
     school = models.CharField(blank=True,max_length=50)  
     user = models.OneToOneField("User", on_delete=models.CASCADE)

在UserExtension模型上增加了一个一对一的关系映射。其实底层是在UserExtension这个表上增加了一个user_id，来和user表进行关联，并且这个外键数据在表中必须是唯一的，来保证一对一。

有时候，我们关联的模型并不在当前模型的文件内，没关系，就像我们导入第三方库一样的从别的模块内导入进来就好，如下例所示：

from django.db import models
from geography.models import ZipCode

class Restaurant(models.Model):
    # ...
    zip_code = models.ForeignKey(
        ZipCode,
        on_delete=models.SET_NULL,
        blank=True,
        null=True,
    )

3.4.6 多对多

Django为这种多对多的实现提供了专门的Field。叫做ManyToManyField 。举个例子比如文章和标签的关系。一篇文章可以有多个标签，一个标签可以被多个文章所引用。因此标签和文章的关系是典型的多对多的关系。

 class Article(models.Model):
     title = models.CharField(max_length=100)
     content = models.TextField()
     tags = models.ManyToManyField("Tag",related_name="articles")

 class Tag(models.Model):
     name = models.CharField(max_length=50)

在数据库层面，实际上Django是为这种多对多的关系建立了一个中间表。这个中间表分别定义了两个外键，引用到article和tag两张表的主键。

ManyToManyField多对多字段不支持Django内置的validators验证功能。

null参数对ManyToManyField多对多字段无效！设置null=True毫无意义

3.4.7 related_name和related_query_name

related_name：

还是以User和Article为例来进行说明。如果一个article想要访问对应的作者，那么可以通过author来进行访问。但是如果有一个user对象，想要通过这个user对象获取所有的文章，该如何做呢？这时候可以通过user.article_set来访问，这个名字的规律是模型名字小写_set。示例代码如下：

user = User.objects.get(name='张三')
user.article_set.all()

如果不想使用模型名字小写_set的方式，想要使用其他的名字，那么可以在定义模型的时候指定related_name。示例代码如下：

class Article(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    # 传递related_name参数，以后在方向引用的时候使用articles进行访问
    author = models.ForeignKey("User",on_delete=models.SET_NULL,null=True,related_name='articles')

以后在方向引用的时候。使用articles可以访问到这个作者的文章模型。示例代码如下：

user = User.objects.get(name='张三')
user.articles.all()

如果不想使用反向引用，那么可以指定related_name='+'。示例代码如下：

class Article(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    # 传递related_name参数，以后在方向引用的时候使用articles进行访问
    author = models.ForeignKey("User",on_delete=models.SET_NULL,null=True,related_name='+')

以后将不能通过user.article_set来访问文章模型了。

related_query_name：

在查找数据的时候，可以使用filter进行过滤。使用filter过滤的时候，不仅仅可以指定本模型上的某个属性要满足什么条件，还可以指定相关联的模型满足什么属性。比如现在想要获取写过标题为abc的所有用户，那么可以这样写：

users = User.objects.filter(article__title='abc')

如果你设置了related_name为articles，因为反转的过滤器的名字将使用related_name的名字，那么上例代码将改成如下：

users = User.objects.filter(articles__title='abc')

可以通过related_query_name将查询的反转名字修改成其他的名字。比如article。示例代码如下：

class Article(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    # 传递related_name参数，以后在方向引用的时候使用articles进行访问
    author = models.ForeignKey("User",on_delete=models.SET_NULL,null=True,related_name='articles',related_query_name='article')

那么在做反向过滤查找的时候就可以使用以下代码：

users = User.objects.filter(article__title='abc')

related_query_name的默认值为 related_name 或 default_related_name

3.5 模型Meta选项

模型的元数据，指的是“除了字段外的所有内容”，例如排序方式、数据库表名、人类可读的单数或者复数名等等。所有的这些都是非必须的，甚至元数据本身对模型也是非必须的。但是，我要说但是，有些元数据选项能给予你极大的帮助，在实际使用中具有重要的作用，是实际应用的‘必须’。

想在模型中增加元数据，方法很简单，在模型类中添加一个子类，名字是固定的Meta，然后在这个Meta类下面增加各种元数据选项或者说设置项。参考下面的例子：

from django.db import models

class Ox(models.Model):
    horn_length = models.IntegerField()

    class Meta:         # 注意，是模型的子类，要缩进！
        ordering = ["horn_length"]
        verbose_name_plural = "oxen"

上面的例子中，我们为模型Ox增加了两个元数据ordering和verbose_name_plural，分别表示排序和复数名。

强调：每个模型都可以有自己的元数据类，每个元数据类也只对自己所在模型起作用。

3.5.1 常可用的元数据选项

abstract：如果abstract=True，那么模型会被认为是一个抽象模型。抽象模型本身不实际生成数据库表，而是作为其它模型的父类，被继承使用。具体内容可以参考Django模型的继承。
app_label:如果定义了模型的app没有在INSTALLED_APPS中注册，则必须通过此元选项声明它属于哪个app，例如：

app_label = 'myapp'

base_manager_name：自定义模型的_base_manager管理器的名字。模型管理器是Django为模型提供的API所在。
db_table：指定在数据库中，当前模型生成的数据表的表名。比如：

db_table = 'my_freinds'

友情建议：使用MySQL数据库时，db_table用小写英文。

default_manager_name：自定义模型的_default_manager管理器的名字。
default_related_name：默认情况下，从一个模型反向关联设置有关系字段的源模型，我们使用_set，也就是源模型的名字+下划线+set。

这个元数据选项可以让你自定义反向关系名，同时也影响反向查询关系名！看下面的例子：

from django.db import models

class Foo(models.Model):
    pass

class Bar(models.Model):
    foo = models.ForeignKey(Foo)

    class Meta:
        default_related_name = 'bars'   # 关键在这里

具体的使用差别如下：

>>> bar = Bar.objects.get(pk=1)
>>> # 不能再使用"bar"作为反向查询的关键字了。
>>> Foo.objects.get(bar=bar)
>>> # 而要使用你自己定义的"bars"了。
>>> Foo.objects.get(bars=bar)

ordering：最常用的元数据之一了！

用于指定该模型生成的所有对象的排序方式，接收一个字段名组成的元组或列表。默认按升序排列，如果在字段名前加上字符“-”则表示按降序排列，如果使用字符问号“？”表示随机排列。请看下面的例子：

ordering = ['pub_date']             # 表示按'pub_date'字段进行升序排列
ordering = ['-pub_date']            # 表示按'pub_date'字段进行降序排列
ordering = ['-pub_date', 'author']  # 表示先按'pub_date'字段进行降序排列，再按`author`字段进行升序排列。

permissions：该元数据用于当创建对象时增加额外的权限。它接收一个所有元素都是二元元组的列表或元组，每个元素都是(权限代码, 直观的权限名称)的格式。比如下面的例子：

permissions = (("can_deliver_pizzas", "可以送披萨"),)

default_permissions：Django默认给所有的模型设置(add, change, delete)的权限，也就是增删改。你可以自定义这个选项，比如设置为一个空列表，表示你不需要默认的权限，但是这一操作必须在执行migrate命令之前。
proxy：如果设置了proxy = True，表示使用代理模式的模型继承方式。
indexes：接收一个应用在当前模型上的索引列表，如下例所示：

from django.db import models

class Customer(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=['last_name', 'first_name']),
            models.Index(fields=['first_name'], name='first_name_idx'),
        ]

12 . verbose_name：最常用的元数据之一！用于设置模型对象的直观、人类可读的名称。可以用中文。例如：

verbose_name = "story"
verbose_name = "披萨"

如果你不指定它，那么Django会使用小写的模型名作为默认值。

至于Meta其他的元数据选项可以查看官方文档

3.6 Mode类的常用的方法与属性

3.6.1 Mode类的常用属性

objects属性，Model.objects实际上是一个 Manager对象实例， Django规定在模型类中至少有一个默认值 Manager，如果你不添加自己的 Manager，django将添加一个属性objects包含默认值Manager实例。如果你添加你自己的Manager实例属性，不显示默认属性。 Manager对象实例主要用于模型类的查询操作，请考虑以下示例：

from django.db import models

class Person(models.Model):
    # 添加一个其他名字的管理器
    people = models.Manager()

3.6.2 Mode类的常用预定义方法

save()：将对象保存回数据库

article = Article(title='abc',content='123')
article.save()

delete()：这只会删除数据库中的对象；python实例仍然存在，并且其字段中仍有数据。此方法返回已删除的对象数和一个字典，其中包含每个对象类型的删除数。

book = Book.objects.get(name='三国演义')
book.delete()

3.7 数据库模型映射到数据库

将定义好的数据库模型类映射到数据库中分两步：

(1). 通过Django自带的命令：python manage.py makemigrations生成迁移脚本

(2). 再通过Django自带命令python manage.py migrate执行迁移

注意：

在迁移前没有添加到settings INSTALL_APP配置项中的应用中的模型类是不会映射到数据库中
在第一次迁移时，Django会生成一些自带的表，这些表对应的模型是Django自动创建的，创建项目时Django自动把一些默认的应用放到了settings.py文件中的 INSTALL_APP配置项中，这些应用大多是session、admin后台、auth权限认证相关的应用，这些应用都有自己的模型类，所有迁移时会生成一些表

3.7.1 迁移命令

makemigrations：将模型生成迁移脚本。这个命令有以下几个常用选项：
- app_label：后面可以跟一个或者多个app，那么就只会针对这几个app生成迁移脚本。如果没有任何的app_label，那么会检查INSTALLED_APPS中所有的app下的模型，针对每一个app都生成响应的迁移脚本。
- --name：给这个迁移脚本指定一个名字。
- --empty：生成一个空的迁移脚本。如果你想写自己的迁移脚本，可以使用这个命令来实现一个空的文件，然后自己再在文件中写迁移脚本。
migrate：将新生成的迁移脚本。映射到数据库中。创建新的表或者修改表的结构。以下一些常用的选项：
- app_label：将某个app下的迁移脚本映射到数据库中。如果没有指定，那么会将所有在INSTALLED_APPS中的app下的模型都映射到数据库中。
- app_label migrationname：将某个app下指定名字的migration文件映射到数据库中。
- --fake：可以将指定的迁移脚本名字添加到数据库中。但是并不会把迁移脚本转换为SQL语句，修改数据库中的表。
- --fake-initial：将第一次生成的迁移文件版本号记录在数据库中。但并不会真正的执行迁移脚本。
showmigrations：查看某个app下的迁移文件。如果后面没有app，那么将查看INSTALLED_APPS中所有的迁移文件。
sqlmigrate：查看某个迁移文件在映射到数据库中的时候，转换的SQL语句。

3.7.2 迁移常见问题

migrations中的迁移版本和数据库中的迁移版本对不上：

找到哪里不一致，然后使用python manage.py --fake [版本名字]，将这个版本标记为已经映射。
删除指定app下migrations和数据库表django_migrations中和这个app相关的版本号，然后将模型中的字段和数据库中的字段保持一致，再使用命令python manage.py makemigrations重新生成一个初始化的迁移脚本，之后再使用命令python manage.py makemigrations --fake-initial来将这个初始化的迁移脚本标记为已经映射。以后再修改就没有问题了。

3.7.3 根据已有的表自动生成模型

在实际开发中，有些时候可能数据库已经存在了。如果我们用Django来开发一个网站，读取的是之前已经存在的数据库中的数据。那么该如何将模型与数据库中的表映射呢？根据旧的数据库生成对应的ORM模型，需要以下几个步骤：

Django给我们提供了一个inspectdb的命令，可以非常方便的将已经存在的表，自动的生成模型。想要使用inspectdb自动将表生成模型。首先需要在settings.py中配置好数据库相关信息。不然就找不到数据库。示例代码如下：

 DATABASES = {
     'default': {
         'ENGINE': 'django.db.backends.mysql',
         'NAME': "migrations_demo",
         'HOST': '127.0.0.1',
         'PORT': '3306',
         'USER': 'root',
         'PASSWORD': 'root'
     }
 }

比如有以下表：

article表：

article表.png
tag表：

tag表.png
article_tag表：

article_tag表.png

front_user表：

frontuser.png
那么通过python manage.py inspectdb，就会将表转换为模型后的代码，显示在终端：

from django.db import models

class ArticleArticle(models.Model):
  title = models.CharField(max_length=100)
  content = models.TextField(blank=True, null=True)
  create_time = models.DateTimeField(blank=True, null=True)
  author = models.ForeignKey('FrontUserFrontuser', models.DO_NOTHING, blank=True, null=True)

  class Meta:
      managed = False
      db_table = 'article_article'

class ArticleArticleTags(models.Model):
  article = models.ForeignKey(ArticleArticle, models.DO_NOTHING)
  tag = models.ForeignKey('ArticleTag', models.DO_NOTHING)

  class Meta:
      managed = False
      db_table = 'article_article_tags'
      unique_together = (('article', 'tag'),)

class ArticleTag(models.Model):
  name = models.CharField(max_length=100)

  class Meta:
      managed = False
      db_table = 'article_tag'

class FrontUserFrontuser(models.Model):
  username = models.CharField(max_length=100)
  telephone = models.CharField(max_length=11)

  class Meta:
      managed = False
      db_table = 'front_user_frontuser'

以上代码只是显示在终端。如果想要保存到文件中。那么可以使用>重定向输出到指定的文件。比如让他输出到models.py文件中。示例命令如下：

python manage.py inspectdb > models.py

以上的命令，只能在终端执行，不能在pycharm->Tools->Run manage.py Task...中使用。

如果只是想要转换一个表为模型。那么可以指定表的名字。示例命令如下：

python manage.py inspectdb article_article > models.py

修正模型：新生成的ORM模型有些地方可能不太适合使用。比如模型的名字，表之间的关系等等。那么以下选项还需要重新配置一下：
- 模型名：自动生成的模型，是根据表的名字生成的，可能不是你想要的。这时候模型的名字你可以改成任何你想要的。
- 模型所属app：根据自己的需要，将相应的模型放在对应的app中。放在同一个app中也是没有任何问题的。只是不方便管理。
- 模型外键引用：将所有使用ForeignKey的地方，模型引用都改成字符串。这样不会产生模型顺序的问题。另外，如果引用的模型已经移动到其他的app中了，那么还要加上这个app的前缀。
- 让Django管理模型：将Meta下的managed=False删掉，如果保留这个，那么以后这个模型有任何的修改，使用migrate都不会映射到数据库中。
- 当有多对多的时候，应该也要修正模型。将中间表注视了，然后使用ManyToManyField来实现多对多。并且，使用ManyToManyField生成的中间表的名字可能和数据库中那个中间表的名字不一致，这时候肯定就不能正常连接了。那么可以通过db_table来指定中间表的名字。示例代码如下：
```
class Article(models.Model):
 title = models.CharField(max_length=100, blank=True, null=True)
 content = models.TextField(blank=True, null=True)
 author = models.ForeignKey('front.User', models.SET_NULL, blank=True, null=True)
 # 使用ManyToManyField模型到表，生成的中间表的规则是：article_tags
 # 但现在已经存在的表的名字叫做：article_tag
 # 可以使用db_table，指定中间表的名字
 tags = models.ManyToManyField("Tag",db_table='article_tag')

 class Meta:
     db_table = 'article'
```
- 表名：切记不要修改表的名字。不然映射到数据库中，会发生找不到对应表的错误。
执行命令python manage.py makemigrations生成初始化的迁移脚本。方便后面通过ORM来管理表。这时候还需要执行命令python manage.py migrate --fake-initial，因为如果不使用--fake-initial，那么会将迁移脚本会映射到数据库中。这时候迁移脚本会新创建表，而这个表之前是已经存在了的，所以肯定会报错。此时我们只要将这个0001-initial的状态修改为已经映射，而不真正执行映射，下次再migrate的时候，就会忽略他。
将Django的核心表映射到数据库中：Django中还有一些核心的表也是需要创建的。不然有些功能是用不了的。比如auth相关表。如果这个数据库之前就是使用Django开发的，那么这些表就已经存在了。可以不用管了。如果之前这个数据库不是使用Django开发的，那么应该使用migrate命令将Django中的核心模型映射到数据库中。