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

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

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

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

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

    class Meta:
        abstract = True

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

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

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

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

這里的 ?default_manager ?是默認的。 ?objects ?管理器仍然可用，因為它是繼承的，但沒有被當(dāng)做默認管理器。
最后，對于這個示例，假設(shè)您想要向子類中添加額外的管理器，但是仍然使用來自 ?AbstractBase ?的默認管理器。您不能直接在子類中添加新的管理器，因為這將覆蓋默認管理器，并且您還必須顯式地申明來自抽象基類的所有管理器。解決方案是將這個管理器放到另一個基類中，并在默認管理器 之后 將其引入繼承層次結(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

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

ClassA.objects.do_something()

上述是合法的，但如下會引發(fā)一個異常。這是因為管理器意在封裝管理映射對象集合的邏輯。因為您不能擁有抽象對象的集合，所以管理抽象對象是沒有意義的。如果您有適用于抽象模型的功能，則應(yīng)該將該功能放在抽象模型的 靜態(tài)方法 或 類方法 中:

AbstractBase.objects.do_something()