Djangoが送信する全てのシグナルのリストです。全ての組み込みシグナルは send() メソッドを使用して送信されます。
django.db.models.signals モジュールは、モデルシステムによって送信される一連のシグナルを定義しています。
pre_initLink to this heading#Django モデルをインスタンス化するたびに、このシグナルはモデルの __init__() メソッドの開始時に送信されます。
このシグナルとともに送信される引数は以下の通りです:
\nsenderたった今インスタンスが作成されたモデルクラス。
\nargs__init__() に渡される位置引数のリストです。
kwargs__init__() に渡されるキーワード引数の辞書。
例えば、 チュートリアル にはこのような行があります：
\nq = Question(question_text="What's new?", pub_date=timezone.now())\npre_init ハンドラーに送信される引数は次の通りです：
引数 | \n値 | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
post_initLink to this heading#pre_init と似ていますが、このイベントは __init__() メソッドが終了した時に送信されます。
このシグナルとともに送信される引数は以下の通りです:
\nsender上記の通り: たった今インスタンスが作成されたモデルクラス。
\ninstanceたった今作成されたモデルの実際のインスタンス。
\n\npre_saveLink to this heading#これは、モデルの save() メソッドの始まりに送信されます。
このシグナルとともに送信される引数は以下の通りです:
\nsenderモデルクラス。
\ninstance保存される実際のインスタンス。
\nraw真偽値です。モデルがそのままの形 (例えば フィクスチャ を読み込む時) で保存されている場合は True となります。データベースがまだ一貫した状態にない可能性があるため、他のレコードをクエリしたり変更したりするべきではありません。
using使用されているデータベースのエイリアス。
\nupdate_fieldsModel.save() に渡された更新するフィールドのセット、もしくは update_fields が save() に渡されなかった場合は None 。
post_saveLink to this heading#pre_save に似ていますが、 save() メソッドの最後に送信されます。
このシグナルとともに送信される引数は以下の通りです:
\nsenderモデルクラス。
\ninstance保存される実際のインスタンス。
\ncreatedブール値。レコードが作成された場合に True を返す。
raw真偽値です。モデルがそのままの形 (例えば フィクスチャ を読み込む時) で保存されている場合は True となります。データベースがまだ一貫した状態にない可能性があるため、他のレコードをクエリしたり変更したりするべきではありません。
using使用されているデータベースのエイリアス。
\nupdate_fieldsModel.save() に渡された更新するフィールドのセット、もしくは update_fields が save() に渡されなかった場合は None 。
pre_deleteLink to this heading#モデルの delete() メソッドとクエリセットの delete() メソッドの開始時に送信されます。
このシグナルとともに送信される引数は以下の通りです:
\nsenderモデルクラス。
\ninstance実際に削除されるインスタンス。
\nusing使用されているデータベースのエイリアス。
\noriginThe Model or QuerySet instance from which the deletion originated,\nthat is, the instance whose delete() method was invoked.
post_deleteLink to this heading#pre_delete のようですが、モデルの delete() メソッドとクエリセットの delete() メソッドの終わりに送信されます。
このシグナルとともに送信される引数は以下の通りです:
\nsenderモデルクラス。
\ninstance実際に削除されるインスタンス。
\nこのオブジェクトはデータベース内に存在しなくなるため、このインスタンスをどのように扱うか非常に注意してください。
\nusing使用されているデータベースのエイリアス。
\noriginThe Model or QuerySet instance from which the deletion originated,\nthat is, the instance whose delete() method was invoked.
m2m_changedLink to this heading#モデルインスタンス上の ManyToManyField が変更されたときに送信されます。厳密には、これはモデルシグナルではありません。なぜなら、これは ManyToManyField によって送信されるためです。しかし、モデルへの変更を追跡する際に、 pre_save/post_save および pre_delete/post_delete を補完するものであるため、ここに含まれています。
このシグナルとともに送信される引数は以下の通りです:
\nsenderManyToManyField を記述する中間モデルクラスです。多対多フィールドが定義されたときに自動的に作成されます。多対多フィールドの through 属性を使用してアクセスできます。
instance多対多のリレーションが更新されたインスタンス。これは sender のインスタンス、または ManyToManyField が関連づけられているクラスのインスタンスのいずれかです。
actionリレーションに対して行われた更新の種類を表す文字列です。次のいずれかの値を取ります。
\n"pre_add"リレーションにオブジェクトが1つ以上追加される 前 に送信されます。
\n"post_add"リレーションに1つ以上のオブジェクトが追加された 後 に送信されます。
\n"pre_remove"リレーションから 1 つ以上のオブジェクトが削除される 前 に送信されます。
\n"post_remove"リレーションから1つ以上のオブジェクトが削除された 後に 送信されます。
\n"pre_clear"リレーションがクリアされる 前に 送信されます。
\n"post_clear"リレーションがクリアされた 後 に送信されます。
\nreverseリレーションのどちらの側が更新されているかを示します (つまり、更新されているのが順方向のリレーションか、逆方向のリレーションかを表します)。
\nmodelリレーションに追加、削除、またはクリアされるオブジェクトのクラス。
\npk_setpre_add と post_add アクションの場合、これはリレーションに追加される、または追加されたプライマリキー値のセットです。既存の値をフィルタリングしてデータベースの IntegrityError を避ける必要があるため、追加されることが提出された値のサブセットである可能性があります。
pre_remove と post_remove アクションにおいて、これはリレーションから削除されることが提案されたプライマリキーの値のセットです。これは、値が実際に削除されるか、または削除されたかどうかに依存しません。特に、存在しない値が提出されることもあり、pk_set に表示されますが、データベースには影響を与えません。
pre_clear と post_clear アクションの場合、これは None です。
using使用されているデータベースのエイリアス。
\nたとえば、Pizza が複数の Topping オブジェクトを持てるとしたら、次のようにモデル化されます。
class Topping(models.Model):\n # ...\n pass\n\n\nclass Pizza(models.Model):\n # ...\n toppings = models.ManyToManyField(Topping)\nこのようにハンドラーを接続した場合：
\nfrom django.db.models.signals import m2m_changed\n\n\ndef toppings_changed(sender, **kwargs):\n # Do something\n pass\n\n\nm2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)\nそして、次のようにした場合:
\n>>> p = Pizza.objects.create(...)\n>>> t = Topping.objects.create(...)\n>>> p.toppings.add(t)\nm2m_changed ハンドラ (上記の例では toppings_changed) に送信された引数は、次の通りです:
引数 | \n値 | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
そして、次のようなことをした場合：
\n>>> t.pizza_set.remove(p)\nm2m_changed ハンドラに送信される引数は以下の通りです:
引数 | \n値 | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
class_preparedLink to this heading#モデルクラスが「準備完了」したとき――つまり、モデルが定義され、Djangoのモデルシステムに登録された後に送信されます。Djangoはこのシグナルを内部的に使用しています。通常、サードパーティのアプリケーションで使用されることはありません。
\nこのシグナルはアプリ登録プロセス中に送信されます。そして AppConfig.ready() はアプリ登録が完全に終了した後に実行されますので、レシーバーをそのメソッド内で接続することはできません。一つの可能性としては、 AppConfig.__init__() の中でそれらを接続することですが、モデルをインポートしたり、アプリ登録への呼び出しを触発しないよう注意が必要です。
このシグナルで送信される引数：
\nsenderたった今準備されたモデルクラス。
\ndjango-admin によって送信されるシグナル。
\npre_migrateLink to this heading#migrate コマンドによって、アプリケーションのインストールを開始する前に送信されます。models モジュールがないアプリケーションには発行されません。
このシグナルとともに送信される引数は以下の通りです:
\nsenderマイグレーションまたは同期される予定のアプリケーションのための AppConfig インスタンスです。
app_configsender と同じ。
verbositymanage.py が画面上にどれだけ情報を表示しているかを示します。詳細については --verbosity フラグを参照してください。
pre_migrate のためにリスナーとなる関数は、この引数の値に基づいて画面出力を調整するべきです。
interactiveinteractive が True の場合、コマンドラインでユーザーに入力を求めるのは安全です。 interactive が False の場合、このシグナルを待ち受ける関数は何も求めてはいけません。
たとえば、django.contrib.auth アプリは、interactive が True のときのみスーパーユーザーの作成を促します。
stdout冗長な出力をリダイレクトすべきストリームのようなオブジェクト。
\nusingコマンドが操作を行うデータベースのエイリアスです。
\nplanマイグレーション実行に使用されるマイグレーションプランです。プランはパブリックAPIではありませんが、プランを知る必要がある稀なケースに対応します。プランは2値タプルのリストで、最初の項目はマイグレーションクラスのインスタンスであり、2番目の項目はマイグレーションがロールバックされた (True) か適用された (False) かを示します。
appsマイグレーションを実行する前のプロジェクトの状態を含む Apps のインスタンスです。操作を行いたいモデルを取得するために、グローバルな apps レジストリの代わりに使用すべきです。
post_migrateLink to this heading#migrate コマンドの終わりに (マイグレーションが行われなくても)、そして flush コマンドの後に送信されます。models モジュールがないアプリケーションには発行されません。
このシグナルのハンドラは、データベーススキーマの変更を行ってはなりません。なぜなら、そのような変更を行うと、migrate コマンド実行中に flush コマンドが失敗する可能性があるからです。
このシグナルとともに送信される引数は以下の通りです:
\nsenderインストールされたばかりのアプリケーション用の AppConfig インスタンスです。
app_configsender と同じ。
verbositymanage.py が画面上にどれだけ情報を表示しているかを示します。詳細については --verbosity フラグを参照してください。
post_migrate を待ち受ける関数は、この引数の値に基づいて画面に出力する内容を調整する必要があります。
interactiveinteractive が True の場合、コマンドラインでユーザーに入力を求めるのは安全です。 interactive が False の場合、このシグナルを待ち受ける関数は何も求めてはいけません。
たとえば、django.contrib.auth アプリは、interactive が True のときのみスーパーユーザーの作成を促します。
stdout冗長な出力をリダイレクトすべきストリームのようなオブジェクト。
\nusing同期に使用されるデータベースエイリアスです。デフォルトは default データベースです。
planマイグレーション実行に使用されたマイグレーションプラン。プランはパブリックAPIではありませんが、プランを知る必要がある稀な場合に対応します。プランは2値タプルのリストで、最初の項目はマイグレーションクラスのインスタンスであり、2番目の項目はマイグレーションがロールバックされたか（True）適用されたか（False）を示します。
appsマイグレーション実行後のプロジェクトの状態を保持する Apps のインスタンスです。グローバルな apps レジストリの代わりに、操作を行いたいモデルを取得するために使用するべきです。
たとえば、次のように AppConfig にコールバックを登録できます:
from django.apps import AppConfig\nfrom django.db.models.signals import post_migrate\n\n\ndef my_callback(sender, **kwargs):\n # Your specific logic here\n pass\n\n\nclass MyAppConfig(AppConfig):\n ...\n\n def ready(self):\n post_migrate.connect(my_callback, sender=self)\nリクエストを処理する際にコアフレームワークによって送信されるシグナル。
\n\nrequest_startedLink to this heading#Django が HTTP リクエストの処理を開始したときに送信されます。
\nこのシグナルとともに送信される引数は以下の通りです:
\nsenderリクエストを処理したハンドラクラス。例えば django.core.handlers.wsgi.WsgiHandler が該当します。
environリクエストに提供される environ 辞書。
request_finishedLink to this heading#クライアントへの HTTP レスポンスの配信が完了したときに送信されます。
\nこのシグナルとともに送信される引数は以下の通りです:
\nsender上述のようなハンドラークラスです。
\ngot_request_exceptionLink to this heading#このシグナルは、Djangoが受信HTTPリクエストの処理中に例外に遭遇したときにいつでも送信されます。
\nこのシグナルとともに送信される引数は以下の通りです:
\nsender使用されません (常に None)。
requestHttpRequest オブジェクト。
テストを 実行しているとき のみ送信されるシグナル。
\nsetting_changedLink to this heading#このシグナルは、 django.test.TestCase.settings() コンテキストマネージャや django.test.override_settings() デコレータ/コンテキストマネージャを通じて設定の値が変更されたときに送信されます。
実際には2回送信されます。新しい値が適用されたとき（"setup"）と、元の値が復元されたとき（"teardown"）。2つを区別するには、enter 引数を使用してください。
このシグナルは django.core.signals からインポートすることもできます。これにより、テスト以外の状況で django.test からインポートすることを避けられます。
このシグナルとともに送信される引数は以下の通りです:
\nsender設定ハンドラ。
\nsetting設定の名前。
\nvalue設定変更後の設定値です。初めに存在しない設定の場合、 "teardown" フェーズでは value は None です。
enter真偽値。設定が適用されている場合は True、復元された場合は False。
template_renderedLink to this heading#テストシステムがテンプレートをレンダリングするときに送信されます。このシグナルは、Djangoサーバーの通常の操作中には発生しません。テスト中にのみ利用可能です。
\nこのシグナルとともに送信される引数は以下の通りです:
\n\nデータベース接続が開始されたときに、データベースラッパーによって送信されるシグナル。
\nconnection_createdLink to this heading#データベースラッパーがデータベースに最初の接続を行ったときに送信されます。これは、SQLバックエンドに接続後のコマンドを送信したい場合に特に便利です。
\nこのシグナルとともに送信される引数は以下の通りです:
\nsenderデータベースラッパークラス ― つまり、 django.db.backends.postgresql.DatabaseWrapper や django.db.backends.mysql.DatabaseWrapper などです。
connectionオープンされたデータベース接続です。これは、複数のデータベース設定を使用する際に、異なるデータベースからの接続シグナルを区別するために使用されます。
\n