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"
"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
) に送信された引数は、次の通りです:
引数 | 値 |
---|---|
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
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
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
value
は None
です。enter
True
、復元された場合は False
。データベース接続が開始されたときに、データベースラッパーによって送信されるシグナル。
connection_created
¶django.db.backends.signals.
connection_created
¶データベースラッパーがデータベースに最初の接続を行ったときに送信されます。これは、SQLバックエンドに接続後のコマンドを送信したい場合に特に便利です。
このシグナルとともに送信される引数は以下の通りです:
sender
django.db.backends.postgresql.DatabaseWrapper
や django.db.backends.mysql.DatabaseWrapper
などです。connection
8月 06, 2024