Django4.0 管理器-自定義管理器和模型繼承

下面是Django如何處理自定義管理器和模型繼承：

1. 基類的管理器總是被子類以 Python 的普通名稱解析順序繼承（子類上的屬性會(huì)覆蓋所有父類上的同名屬性；直接父類會(huì)覆蓋更上一級(jí)的，以此類推）。
2. 如果沒有在模型或其父類申明管理器，Django 會(huì)自動(dòng)創(chuàng)建 ?objects ?管理器。
3. 一個(gè)類的默認(rèn)管理器要么由 ?Meta.default_manager_name? 指定，要么是模型中申明的第一個(gè)管理器，或者是直接父模型的默認(rèn)管理器。

如果您想通過抽象基類在一組模型上安裝自定義管理器，但仍能自定義默認(rèn)管理器，這些規(guī)則提供了必要的靈活性。例如，假設(shè)有此基類:

class AbstractBase(models.Model):
    # ...
    objects = CustomManager()

    class Meta:
        abstract = True

如果您在子類中直接使用這一點(diǎn)，如果您在基類中沒有聲明任何管理器，那么 ?objects將是默認(rèn)的管理器：

class ChildA(AbstractBase):
    # ...
    # This class has CustomManager as the default manager.
    pass

如果您想繼承 ?AbstractBase?，但提供不同的默認(rèn)管理器，則可以在子類上提供該默認(rèn)管理器:

class ChildB(AbstractBase):
    # ...
    # An explicit default manager.
    default_manager = OtherManager()

這里的 ?default_manager ?是默認(rèn)的。 ?objects ?管理器仍然可用，因?yàn)樗抢^承的，但沒有被當(dāng)做默認(rèn)管理器。
最后，對(duì)于這個(gè)示例，假設(shè)您想要向子類中添加額外的管理器，但是仍然使用來自 ?AbstractBase ?的默認(rèn)管理器。您不能直接在子類中添加新的管理器，因?yàn)檫@將覆蓋默認(rèn)管理器，并且您還必須顯式地申明來自抽象基類的所有管理器。解決方案是將這個(gè)管理器放到另一個(gè)基類中，并在默認(rèn)管理器 之后 將其引入繼承層次結(jié)構(gòu):

class ExtraManager(models.Model):
    extra_manager = OtherManager()

    class Meta:
        abstract = True

class ChildC(AbstractBase, ExtraManager):
    # ...
    # Default manager is CustomManager, but OtherManager is
    # also available via the "extra_manager" attribute.
    pass

請(qǐng)注意，雖然可以在抽象模型上定義自定義管理器，但不能使用抽象模型 調(diào)用 任何方法。即:

ClassA.objects.do_something()

上述是合法的，但如下會(huì)引發(fā)一個(gè)異常。這是因?yàn)楣芾砥饕庠诜庋b管理映射對(duì)象集合的邏輯。因?yàn)槟荒軗碛谐橄髮?duì)象的集合，所以管理抽象對(duì)象是沒有意義的。如果您有適用于抽象模型的功能，則應(yīng)該將該功能放在抽象模型的 靜態(tài)方法 或 類方法 中:

AbstractBase.objects.do_something()