pre_init¶

django.db.models.signals.pre_init¶

每當您實例化 Django 模型時，此訊號會在模型的 __init__() 方法開始時發送。

此訊號發送的引數

sender

剛建立實例的模型類別。

args

傳遞給 __init__() 的位置引數列表。

kwargs

傳遞給 __init__() 的關鍵字引數字典。

例如，教學課程 中有這一行

q = Question(question_text="What's new?", pub_date=timezone.now())

傳遞給 pre_init 處理程式的引數將會是

post_init¶

django.db.models.signals.post_init¶

與 pre_init 類似，但此訊號在 __init__() 方法完成時發送。

此訊號發送的引數

sender

如上：剛建立實例的模型類別。

instance

剛建立的模型的實際實例。

注意

在發送 post_init 訊號之前，不會設定 instance._state，因此 _state 屬性始終具有其預設值。例如，_state.db 為 None。

pre_save¶

django.db.models.signals.pre_save¶

此訊號在模型的 save() 方法開始時發送。

此訊號發送的引數

sender

模型類別。

instance

正在儲存的實際實例。

raw

布林值；如果模型完全按照呈現的方式儲存（即在載入 fixture 時），則為 True。在資料庫可能尚未處於一致狀態時，不應查詢/修改資料庫中的其他記錄。

using

正在使用的資料庫別名。

update_fields

要更新的欄位集合，如同傳遞給 Model.save() 的欄位集合，如果 update_fields 沒有傳遞給 save()，則為 None。

post_save¶

django.db.models.signals.post_save¶

與 pre_save 類似，但在 save() 方法結束時發送。

此訊號發送的引數

sender

模型類別。

instance

正在儲存的實際實例。

created

布林值；如果建立了新記錄，則為 True。

raw

布林值；如果模型完全按照呈現的方式儲存（即在載入 fixture 時），則為 True。在資料庫可能尚未處於一致狀態時，不應查詢/修改資料庫中的其他記錄。

using

正在使用的資料庫別名。

update_fields

要更新的欄位集合，如同傳遞給 Model.save() 的欄位集合，如果 update_fields 沒有傳遞給 save()，則為 None。

pre_delete¶

django.db.models.signals.pre_delete¶

在模型的 delete() 方法和 queryset 的 delete() 方法開始時發送。

此訊號發送的引數

sender

模型類別。

instance

正在刪除的實際實例。

using

正在使用的資料庫別名。

origin

刪除的來源，為 Model 或 QuerySet 類別的實例。

post_delete¶

django.db.models.signals.post_delete¶

與 pre_delete 類似，但在模型的 delete() 方法和 queryset 的 delete() 方法結束時發送。

此訊號發送的引數

sender

模型類別。

instance

正在刪除的實際實例。

請注意，該物件將不再存在於資料庫中，因此請非常小心您如何使用此實例。

using

正在使用的資料庫別名。

origin

刪除的來源，為 Model 或 QuerySet 類別的實例。

m2m_changed¶

django.db.models.signals.m2m_changed¶

當模型實例上的 ManyToManyField 被變更時發送。嚴格來說，這不是一個模型信號，因為它是由 ManyToManyField 發送的，但由於它在追蹤模型變更時補充了 pre_save/post_save 和 pre_delete/post_delete，因此也包含在此處。

此訊號發送的引數

sender

描述 ManyToManyField 的中間模型類別。當定義多對多欄位時，這個類別會自動建立；您可以使用多對多欄位的 through 屬性來存取它。

instance

其多對多關係被更新的實例。這可以是 sender 的實例，或者是 ManyToManyField 相關聯的類別的實例。

動作（action）

一個字串，指示在關係上完成的更新類型。它可以是以下其中之一：

"pre_add"

在一個或多個物件被新增到關係*之前*發送。

"post_add"

在一個或多個物件被新增到關係*之後*發送。

"pre_remove"

在一個或多個物件從關係中被移除*之前*發送。

"post_remove"

在一個或多個物件從關係中被移除*之後*發送。

"pre_clear"

在關係被清除*之前*發送。

"post_clear"

在關係被清除*之後*發送。

反向（reverse）

指示關係的哪一側被更新（即，正在修改的是正向還是反向關係）。

模型（model）

被新增到、從關係中移除或從關係中清除的物件的類別。

pk_set

對於 pre_add 和 post_add 動作，這是一個將要或已經被添加到關係中的主鍵值集合。這可能是提交要新增的值的子集，因為插入必須過濾現有值，以避免資料庫 IntegrityError。

對於 pre_remove 和 post_remove 動作，這是一個提交要從關係中移除的主鍵值集合。這不取決於這些值是否實際將會或已經被移除。特別是，可能會提交不存在的值，並且它們會出現在 pk_set 中，即使它們對資料庫沒有影響。

對於 pre_clear 和 post_clear 動作，這是 None。

using

正在使用的資料庫別名。

例如，如果一個 Pizza 可以有多個 Topping 物件，像這樣建模：

class Topping(models.Model):
    # ...
    pass


class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)

如果我們像這樣連接一個處理器：

from django.db.models.signals import m2m_changed


def toppings_changed(sender, **kwargs):
    # Do something
    pass


m2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)

然後像這樣做：

>>> p = Pizza.objects.create(...)
>>> t = Topping.objects.create(...)
>>> p.toppings.add(t)

發送到 m2m_changed 處理器（在上面的範例中為 toppings_changed）的參數將會是：

如果我們接著像這樣做：

>>> t.pizza_set.remove(p)

發送到 m2m_changed 處理器的參數將會是：

class_prepared¶

django.db.models.signals.class_prepared¶

每當模型類別被「準備」好時發送 - 也就是說，一旦模型被定義並註冊到 Django 的模型系統。Django 內部使用這個信號；它通常不在第三方應用程式中使用。

由於此信號在應用程式註冊表填充過程中發送，並且 AppConfig.ready() 在應用程式註冊表完全填充後執行，因此接收器無法在該方法中連接。一種可能性是在 AppConfig.__init__() 中連接它們，並注意不要匯入模型或觸發對應用程式註冊表的呼叫。

與此信號一起發送的參數：

sender

剛準備好的模型類別。

pre_migrate¶

django.db.models.signals.pre_migrate¶

在開始安裝應用程式之前，由 migrate 命令發送。它不會針對缺少 models 模組的應用程式發出。

此訊號發送的引數

sender

即將遷移/同步的應用程式的 AppConfig 實例。

app_config

與 sender 相同。

verbosity

指示 manage.py 在螢幕上列印多少資訊。有關詳細資訊，請參閱 --verbosity 旗標。

監聽 pre_migrate 的函式應根據此引數的值調整其在螢幕上的輸出。

interactive

如果 interactive 為 True，則可以在命令列上提示使用者輸入內容。如果 interactive 為 False，則監聽此信號的函式不應嘗試提示任何內容。

例如，django.contrib.auth 應用程式僅在 interactive 為 True 時提示建立超級使用者。

stdout

一個類似串流的物件，應該將詳細輸出重新導向到此處。

using

將在其上執行命令的資料庫別名。

plan

將用於遷移執行的遷移計劃。雖然該計劃不是公共 API，但在少數情況下，有必要了解該計劃。計劃是一個 2 元組列表，第一個項目是遷移類別的實例，第二個項目顯示遷移是否已回滾 (True) 或應用 (False)。

apps

Apps 的實例，其中包含遷移執行之前專案的狀態。應使用它而不是全域的 apps 註冊表來檢索您想要執行操作的模型。

post_migrate¶

django.db.models.signals.post_migrate¶

在 migrate (即使沒有執行遷移) 和 flush 命令結束時發送。對於缺少 models 模組的應用程式，不會發出此訊號。

這個訊號的處理函式不應執行資料庫綱要變更，因為這樣做可能會導致 flush 命令在 migrate 命令期間執行時失敗。

此訊號發送的引數

sender

剛安裝的應用程式的 AppConfig 實例。

app_config

與 sender 相同。

verbosity

指示 manage.py 在螢幕上列印多少資訊。有關詳細資訊，請參閱 --verbosity 旗標。

監聽 post_migrate 的函式應根據此引數的值調整其輸出到螢幕的內容。

interactive

如果 interactive 為 True，則可以在命令列上提示使用者輸入內容。如果 interactive 為 False，則監聽此信號的函式不應嘗試提示任何內容。

例如，django.contrib.auth 應用程式僅在 interactive 為 True 時提示建立超級使用者。

stdout

一個類似串流的物件，應該將詳細輸出重新導向到此處。

using

用於同步的資料庫別名。預設值為 default 資料庫。

plan

用於遷移執行的遷移計畫。雖然該計畫不是公開的 API，但這允許在極少數情況下需要知道該計畫。計畫是一個包含 2 個元素的元組列表，第一個元素是遷移類別的實例，第二個元素顯示遷移是否已回滾 (True) 或已應用 (False)。

apps

包含遷移執行後專案狀態的 Apps 實例。它應該用於代替全域的 apps 註冊表來檢索您想要對其執行操作的模型。

例如，您可以在 AppConfig 中註冊一個回呼函式，如下所示

from django.apps import AppConfig
from django.db.models.signals import post_migrate


def my_callback(sender, **kwargs):
    # Your specific logic here
    pass


class MyAppConfig(AppConfig):
    ...

    def ready(self):
        post_migrate.connect(my_callback, sender=self)

request_started¶

django.core.signals.request_started¶

當 Django 開始處理 HTTP 請求時發送。

此訊號發送的引數

sender

處理請求的處理程式類別 – 例如 django.core.handlers.wsgi.WsgiHandler。

environ

提供給請求的 environ 字典。

request_finished¶

django.core.signals.request_finished¶

當 Django 完成向客戶端傳遞 HTTP 回應時發送。

此訊號發送的引數

sender

處理程式類別，如上所述。

got_request_exception¶

django.core.signals.got_request_exception¶

每當 Django 在處理傳入的 HTTP 請求時遇到異常時，就會發送此訊號。

此訊號發送的引數

sender

未使用 (始終為 None)。

request

HttpRequest 物件。

setting_changed¶

django.test.signals.setting_changed¶

當透過 django.test.TestCase.settings() 環境管理器或 django.test.override_settings() 裝飾器/環境管理器變更設定的值時，會發送此訊號。

實際上會發送兩次：當套用新值時 (“設定”) 和當還原原始值時 (“拆解”)。使用 enter 引數來區分這兩者。

您也可以從 django.core.signals 導入此訊號，以避免在非測試情況下從 django.test 導入。

此訊號發送的引數

sender

設定處理程式。

setting

設定的名稱。

value

變更後設定的值。對於最初不存在的設定，在 “拆解” 階段，value 為 None。

enter

一個布林值；如果套用設定則為 True，如果還原則為 False。

template_rendered¶

django.test.signals.template_rendered¶

當測試系統轉譯範本時發送。此訊號不會在 Django 伺服器的正常操作期間發出，僅在測試期間可用。

此訊號發送的引數

sender

已轉譯的 Template 物件。

template

與發送者相同

context

轉譯範本時使用的 Context。

connection_created¶

django.db.backends.signals.connection_created¶

當資料庫包裝器建立與資料庫的初始連線時發送。如果您想向 SQL 後端發送任何連線後命令，這特別有用。

此訊號發送的引數

sender

資料庫包裝器類別 – 例如 django.db.backends.postgresql.DatabaseWrapper 或 django.db.backends.mysql.DatabaseWrapper 等。

connection

已開啟的資料庫連線。這可以在多個資料庫配置中使用，以區分來自不同資料庫的連線訊號。