シグナル

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__() に渡されるキーワード引数の辞書。

例えば、 チュートリアル にはこのような行があります：

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=datetime.timezone.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

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

origin

削除の起点は、Model または QuerySet クラスのインスタンスです。

post_delete

django.db.models.signals.post_delete

pre_delete のようですが、モデルの delete() メソッドとクエリセットの 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"

リレーションにオブジェクトが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() はアプリ登録が完全に終了した後に実行されますので、レシーバーをそのメソッド内で接続することはできません。一つの可能性としては、 AppConfig.__init__() の中でそれらを接続することですが、モデルをインポートしたり、アプリ登録への呼び出しを触発しないよう注意が必要です。

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

sender

たった今準備されたモデルクラス。

管理シグナル

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

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値タプルのリストで、最初の項目はマイグレーションクラスのインスタンスであり、2番目の項目はマイグレーションがロールバックされた (True) か適用された (False) かを示します。

apps

マイグレーションを実行する前のプロジェクトの状態を含む Apps のインスタンスです。操作を行いたいモデルを取得するために、グローバルな apps レジストリの代わりに使用すべきです。

post_migrate

django.db.models.signals.post_migrate

migrate コマンドの終わりに (マイグレーションが行われなくても)、そして flush コマンドの後に送信されます。models モジュールがないアプリケーションには発行されません。

このシグナルのハンドラは、データベーススキーマの変更を行ってはなりません。なぜなら、そのような変更を行うと、migrate コマンド実行中に flush コマンドが失敗する可能性があるからです。

このシグナルとともに送信される引数は以下の通りです:

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値タプルのリストで、最初の項目はマイグレーションクラスのインスタンスであり、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 インスタンスを sender 引数として提供する場合は、シグナルが ready() で登録されていることを確認してください。 AppConfig は、 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

クライアントへの 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() デコレータ/コンテキストマネージャを通じて設定の値が変更されたときに送信されます。

実際には2回送信されます。新しい値が適用されたとき（"setup"）と、元の値が復元されたとき（"teardown"）。2つを区別するには、enter 引数を使用してください。

このシグナルは django.core.signals からインポートすることもできます。これにより、テスト以外の状況で django.test からインポートすることを避けられます。

このシグナルとともに送信される引数は以下の通りです:

sender

設定ハンドラ。

setting

設定の名前。

value

設定変更後の設定値です。初めに存在しない設定の場合、 "teardown" フェーズでは 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

オープンされたデータベース接続です。これは、複数のデータベース設定を使用する際に、異なるデータベースからの接続シグナルを区別するために使用されます。