# Django 5.0.9.dev20240806133106 ドキュメント

# シグナル

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