信号
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?",
|
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
。
データベースラッパー
データベース接続が開始されたときにデータベースラッパーによって送信されるシグナル。
connection_created
- django.db.backends.signals.connection_created
データベースラッパーがデータベースへの最初の接続を行うときに送信されます。 これは、接続後のコマンドをSQLバックエンドに送信する場合に特に便利です。
このシグナルで送信される引数:
sender
- データベースラッパークラス–つまり
django.db.backends.postgresql.DatabaseWrapper
またはdjango.db.backends.mysql.DatabaseWrapper
など。 connection
- 開かれたデータベース接続。 これを複数データベース構成で使用して、異なるデータベースからの接続信号を区別できます。