シグナル—Djangoドキュメント

信号

Djangoが送信するすべてのシグナルのリスト。 すべての組み込み信号は、 send（）メソッドを使用して送信されます。

も参照してください

信号の登録方法と受信方法については、信号ディスパッチャのドキュメントを参照してください。

認証フレームワークは、ユーザーがログイン/ログアウトしたときに信号を送信します。

モデル信号

django.db.models.signals モジュールは、モデルシステムによって送信される信号のセットを定義します。

警告

これらのシグナルの多くは、__init__()や save（）など、独自のコードでオーバーライドできるさまざまなモデルメソッドによって送信されます。

モデルでこれらのメソッドをオーバーライドする場合、これらのシグナルを送信するには、親クラスのメソッドを呼び出す必要があります。

Djangoはデフォルトで弱参照としてシグナルハンドラーを保存するため、ハンドラーがローカル関数の場合、ガベージコレクションされる可能性があることにも注意してください。 これを防ぐには、シグナルの connect（）を呼び出すときにweak=Falseを渡します。

ノート

モデル信号senderモデルは、完全なアプリケーションラベルを指定することにより、レシーバーを接続するときに遅延参照できます。 たとえば、pollsアプリケーションで定義されたQuestionモデルは、'polls.Question'として参照できます。 この種の参照は、循環インポートの依存関係やスワップ可能なモデルを処理するときに非常に便利です。

pre_init

django.db.models.signals.pre_init

Djangoモデルをインスタンス化するたびに、このシグナルはモデルの__init__()メソッドの開始時に送信されます。

このシグナルで送信される引数：

sender

インスタンスが作成されたばかりのモデルクラス。

args

__init__()に渡される位置引数のリスト。

kwargs

__init__()に渡されるキーワード引数の辞書。

たとえば、 tutorial には次の行があります。

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

pre_init ハンドラーに送信される引数は次のようになります。

口論	価値
sender	Question（クラス自体）
args	[]（__init__()に渡された位置引数がなかったため、空のリスト）
kwargs	{'question_text': "What's new?", 'pub_date': datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)}

post_init

django.db.models.signals.post_init

pre_initと同様ですが、これは__init__()メソッドが終了したときに送信されます。

このシグナルで送信される引数：

sender

上記のように：インスタンスが作成されたばかりのモデルクラス。

instance

作成されたばかりのモデルの実際のインスタンス。

ノート

instance._state は、post_init信号を送信する前に設定されないため、_state属性は常にデフォルト値になります。 たとえば、_state.dbはNoneです。

警告

パフォーマンス上の理由から、pre_initまたはpost_init信号のレシーバーでクエリを実行しないでください。これらは、クエリセットの反復中に返されるインスタンスごとに実行されるためです。

pre_save

django.db.models.signals.pre_save

これは、モデルの save（）メソッドの先頭で送信されます。

このシグナルで送信される引数：

sender

モデルクラス。

instance

保存されている実際のインスタンス。

raw

ブール値; 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

ブール値; Trueモデルが提示されたとおりに保存されている場合（つまり、 フィクスチャをロードするとき）。 データベースがまだ一貫性のある状態になっていない可能性があるため、データベース内の他のレコードをクエリ/変更しないでください。

using

使用されているデータベースエイリアス。

update_fields

Model.save（）に渡されるように更新するフィールドのセット、またはupdate_fieldsがsave()に渡されなかった場合はNone。

pre_delete

django.db.models.signals.pre_delete

モデルの delete（）メソッドとクエリセットの delete（）メソッドの先頭に送信されます。

このシグナルで送信される引数：

sender

モデルクラス。

instance

削除される実際のインスタンス。

using

使用されているデータベースエイリアス。

post_delete

django.db.models.signals.post_delete

pre_delete と同様ですが、モデルの delete（）メソッドとクエリセットの delete（）メソッドの最後に送信されます。

このシグナルで送信される引数：

sender

モデルクラス。

instance

削除される実際のインスタンス。

オブジェクトはデータベースに存在しなくなるため、このインスタンスの操作には十分注意してください。

using

使用されているデータベースエイリアス。

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"

1つ以上のオブジェクトがリレーションに追加される前に送信されました。

"post_add"

1つ以上のオブジェクトがリレーションに追加された後に送信されました。

"pre_remove"

前に送信され、1つ以上のオブジェクトがリレーションから削除されます。

"post_remove"

の後に送信され、1つ以上のオブジェクトがリレーションから削除されました。

"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）に送信される引数は次のようになります。

口論	価値
sender	Pizza.toppings.through（中間m2mクラス）
instance	p（Pizzaインスタンスが変更されています）
action	"pre_add"（"post_add"の別の信号が続く）
reverse	False（Pizzaには ManyToManyField が含まれているため、この呼び出しによって前方関係が変更されます）
model	Topping（Pizzaに追加されたオブジェクトのクラス）
pk_set	{t.id}（Topping tのみがリレーションに追加されたため）
using	"default"（デフォルトのルーターがここに書き込みを送信するため）

そして、私たちがこのようなことをするなら：

>>> t.pizza_set.remove(p)

m2m_changed ハンドラーに送信される引数は次のようになります。

口論	価値
sender	Pizza.toppings.through（中間m2mクラス）
instance	t（Toppingインスタンスが変更されています）
action	"pre_remove"（"post_remove"の別の信号が続く）
reverse	True（Pizzaには ManyToManyField が含まれているため、この呼び出しは逆の関係を変更します）
model	Pizza（Toppingから削除されたオブジェクトのクラス）
pk_set	{p.id}（Pizza pのみがリレーションから削除されたため）
using	"default"（デフォルトのルーターがここに書き込みを送信するため）

class_prepared

django.db.models.signals.class_prepared

モデルクラスが「準備」されたとき、つまりモデルが定義されてDjangoのモデルシステムに登録されたときに送信されます。 Djangoはこのシグナルを内部的に使用します。 通常、サードパーティのアプリケーションでは使用されません。

このシグナルはアプリレジストリの作成プロセス中に送信され、アプリレジストリが完全に作成された後に AppConfig.ready（）が実行されるため、このメソッドでレシーバーを接続することはできません。 1つの可能性は、モデルをインポートしたり、アプリレジストリへの呼び出しをトリガーしたりしないように注意しながら、代わりにそれらを接続することですAppConfig.__init__()。

このシグナルで送信される引数：

sender

用意したばかりのモデルクラス。

管理シグナル

django-admin によって送信されたシグナル。

pre_migrate

django.db.models.signals.pre_migrate

アプリケーションのインストールを開始する前に、：djadmin： `migrate` コマンドによって送信されます。 modelsモジュールがないアプリケーションでは発行されません。

このシグナルで送信される引数：

sender

移行/同期しようとしているアプリケーションの AppConfig インスタンス。

app_config

senderと同じです。

verbosity

manage.pyが画面に印刷している情報の量を示します。 詳細については、--verbosityフラグを参照してください。

pre_migrate をリッスンする関数は、この引数の値に基づいて、画面に出力する内容を調整する必要があります。

interactive

interactiveがTrueの場合、コマンドラインで入力するようにユーザーに求めるのは安全です。 interactiveがFalseの場合、このシグナルをリッスンする関数は、何も要求しないようにする必要があります。

たとえば、 django.contrib.auth アプリは、interactiveがTrueの場合にのみ、スーパーユーザーの作成を求めるプロンプトを表示します。

using

コマンドが動作するデータベースのエイリアス。

plan

移行の実行に使用される移行計画。 プランはパブリックAPIではありませんが、これにより、プランを知る必要があるまれなケースが可能になります。 プランは2つのタプルのリストであり、最初の項目は移行クラスのインスタンスであり、2番目の項目は移行がロールバックされたか（True）、適用されたか（False）を示します。

apps

移行実行前のプロジェクトの状態を含む Apps のインスタンス。 操作を実行するモデルを取得するには、グローバル apps レジストリの代わりに使用する必要があります。

post_migrate

django.db.models.signals.post_migrate

：djadmin： `migrate` （移行が実行されていない場合でも）および：djadmin：` flush` コマンドの最後に送信されます。 modelsモジュールがないアプリケーションでは発行されません。

：djadmin： `migrate` コマンド中に実行すると、：djadmin：` flush` コマンドが失敗する可能性があるため、このシグナルのハンドラーはデータベーススキーマの変更を実行しないでください。

このシグナルで送信される引数：

sender

インストールされたばかりのアプリケーションの AppConfig インスタンス。

app_config

senderと同じです。

verbosity

manage.pyが画面に印刷している情報の量を示します。 詳細については、--verbosityフラグを参照してください。

post_migrate をリッスンする関数は、この引数の値に基づいて、画面に出力する内容を調整する必要があります。

interactive

interactiveがTrueの場合、コマンドラインで入力するようにユーザーに求めるのは安全です。 interactiveがFalseの場合、このシグナルをリッスンする関数は、何も要求しないようにする必要があります。

たとえば、 django.contrib.auth アプリは、interactiveがTrueの場合にのみ、スーパーユーザーの作成を求めるプロンプトを表示します。

using

同期に使用されるデータベースエイリアス。 デフォルトはdefaultデータベースです。

plan

移行の実行に使用された移行計画。 プランはパブリックAPIではありませんが、これにより、プランを知る必要があるまれなケースが可能になります。 プランは2つのタプルのリストであり、最初の項目は移行クラスのインスタンスであり、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)

ノート

送信側引数として AppConfig インスタンスを指定する場合は、シグナルが ready（）に登録されていることを確認してください。 AppConfigは、：setting： `INSTALLED_APPS` の変更されたセット（設定がオーバーライドされた場合など）で実行されるテスト用に再作成され、そのような信号は新しいAppConfigインスタンス。

リクエスト/レスポンスシグナル

リクエストの処理時にコアフレームワークによって送信されるシグナル。

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

このシグナルは、着信HTTPリクエストの処理中にDjangoが例外を検出するたびに送信されます。

このシグナルで送信される引数：

sender

未使用（常にNone）。

request

HttpRequest オブジェクト。

テスト信号

テストの実行の場合にのみ送信される信号。

setting_changed

django.test.signals.setting_changed

このシグナルは、django.test.TestCase.settings()コンテキストマネージャーまたは django.test.override_settings（）デコレーター/コンテキストマネージャーを介して設定の値が変更されたときに送信されます。

実際には、新しい値が適用されたとき（「セットアップ」）と元の値が復元されたとき（「ティアダウン」）の2回送信されます。 enter引数を使用して、2つを区別します。

この信号を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

テンプレートがレンダリングされたコンテキスト。

データベースラッパー

データベース接続が開始されたときにデータベースラッパーによって送信されるシグナル。

connection_created

django.db.backends.signals.connection_created

データベースラッパーがデータベースへの最初の接続を行うときに送信されます。 これは、接続後のコマンドをSQLバックエンドに送信する場合に特に便利です。

このシグナルで送信される引数：

sender

データベースラッパークラス–つまり django.db.backends.postgresql.DatabaseWrapperまたはdjango.db.backends.mysql.DatabaseWrapperなど。

connection

開かれたデータベース接続。 これを複数データベース構成で使用して、異なるデータベースからの接続信号を区別できます。