Django には "シグナルディスパッチャ" があり、フレームワークの他の場所でアクションが発生したときに、ほかのアプリケーションが通知を受けるのを助けてくれます。簡単に言うと、シグナルは特定の 送り手 が、あるアクションが発生したことを一連の 受け手 に通知できるようにします。特に、多くのコードが同じイベントに関連している場合に便利です。
\n例えば、サードパーティのアプリを登録して、設定変更の通知を受けることができます:
\nfrom django.apps import AppConfig\nfrom django.core.signals import setting_changed\n\n\ndef my_callback(sender, **kwargs):\n print("Setting changed!")\n\n\nclass MyAppConfig(AppConfig):\n ...\n\n def ready(self):\n setting_changed.connect(my_callback)\nDjango の 組み込みのシグナル は、ユーザコードに特定のアクションを通知します。
\nまた、独自のカスタムシグナルを定義して送信することもできます。以下の シグナルの定義と送信 を参照してください。
\n\nシグナルを受信するには、 Signal.connect() メソッドを使って receiver 関数を登録します。シグナルが送信されると、レシーバ関数が呼び出されます。シグナルのすべてのレシーバ関数は、登録された順番に1つずつ呼び出されます。
receiver -- このシグナルに接続されるコールバック関数です。詳しくは レシーバ関数 を参照してください。
sender -- シグナルを受信する送信者を指定します。詳しくは 特定の送信者によって送られたシグナルに接続する を参照してください。
weak -- Django はデフォルトでシグナルハンドラを弱い参照として保存します。従って、レシーバがローカル関数の場合、ガベージコレクションされる可能性 があります。これを防ぐには、シグナルの connect() メソッドを呼び出すときに weak=False を渡してください。
dispatch_uid -- シグナルが重複して送信される可能性がある場合の、シグナル受信機の一意な識別子。詳しくは 重複したシグナルを防止する を参照してください。
HTTP リクエストが終了するたびに呼び出されるシグナルを登録することで、この仕組みを見てみましょう。ここでは request_finished シグナルに接続します。
まず、レシーバ関数を定義する必要があります。レシーバはPythonの関数やメソッドであれば何でもかまいません:
\ndef my_callback(sender, **kwargs):\n print("Request finished!")\nこの関数は sender 引数とワイルドカードキーワード引数 (**kwargs) を取ることに注意してください。すべてのシグナルハンドラはこれらの引数を取らなければなりません。
送信者については もう少し後で 見るので、今は **kwargs 引数を見てください。すべてのシグナルはキーワード引数を送信し、いつでもそのキーワード引数を変更できます。 request_finished の場合、引数を送らないようにドキュメント化されているので、シグナル処理を my_callback(sender) と書きたくなるかもしれません。
これは間違いです。実際、そうすると Django はエラーを返します。というのも、シグナルに引数が追加される可能性があり、レシーバはその新しい引数を扱えなければならないからです。
\nレシーバーは同じシグネチャーを持ち、async def を使って宣言された非同期関数になることもできます:
async def my_callback(sender, **kwargs):\n await asyncio.sleep(5)\n print("Request finished!")\nシグナルは同期でも非同期でも送ることができ、受信側は自動的に正しいコールスタイルに合わせられます。詳細は シグナルを送る を参照してください。
\n\n受信機を信号に接続する方法は2つあります。手動で接続する方法です:
\nfrom django.core.signals import request_finished\n\nrequest_finished.connect(my_callback)\nあるいは、 receiver() デコレータを使うこともできます:
signal -- 関数を接続するシグナルまたはシグナルのリスト。
kwargs -- 関数 に渡すワイルドカードキーワード引数です。
下記がデコレーターとの繋げ方です:
\nfrom django.core.signals import request_finished\nfrom django.dispatch import receiver\n\n\n@receiver(request_finished)\ndef my_callback(sender, **kwargs):\n print("Request finished!")\nこれで、リクエストが終了するたびに my_callback 関数が呼ばれるようになります。
シグナルの中には何度も送信されるものがありますが、そのようなシグナルの特定のサブセットだけを受信したいと思うかも知れません。例えば、モデルが保存される前に送られるシグナル django.db.models.signals.pre_save を考えてみましょう。ほとんどの場合、 どの モデルが保存されるかを知る必要はありません。ある 特定の モデルが保存されたときだけ知る必要があります。
このような場合、特定の送信者のみが送信するシグナルを受信するように登録できます。 django.db.models.signals.pre_save の場合、送信者は保存されるモデルクラスになるので、あるモデルから送信されるシグナルだけが欲しいことを示すことができます:
from django.db.models.signals import pre_save\nfrom django.dispatch import receiver\nfrom myapp.models import MyModel\n\n\n@receiver(pre_save, sender=MyModel)\ndef my_handler(sender, **kwargs): ...\nmy_handler 関数は MyModel のインスタンスが保存されたときにだけ呼び出されます。
異なるシグナルは異なるオブジェクトを送信元として使用します。それぞれのシグナルの詳細については 組み込みシグナルのドキュメント を参照する必要があります。
\n状況によっては、レシーバーをシグナルに接続するコードが複数回実行されることがあります。そのため、レシーバ関数が複数回登録され、シグナルイベントに対して複数回呼び出される可能性があります。例えば、 ready() メソッドがテスト中に複数回実行されるかもしれません。より一般的には、シグナル登録はインポートされた回数だけ実行されるため、 シグナルを定義したモジュールをインポートしたプロジェクトではどこでも発生します。
この動作が問題となる場合 (シグナルを使用してモデルが保存されるたびにメールを送信する場合など)、受信関数を識別するために dispatch_uid 引数に一意な識別子を渡します。この識別子は通常文字列ですが、ハッシュ可能なオブジェクトであれば何でもかまいません。この結果、受信関数は一意な dispatch_uid の値ごとに一度だけシグナルにバインドされることになります:
from django.core.signals import request_finished\n\nrequest_finished.connect(my_callback, dispatch_uid="my_unique_identifier")\nアプリケーションは信号インフラを利用し、独自の信号を提供できます。
\n\nすべてのシグナルは django.dispatch.Signal インスタンスです。
例:
\nimport django.dispatch\n\npizza_done = django.dispatch.Signal()\nこのコードは、pizza_done シグナルを宣言しています。
Django でシグナルを同期的に送信する方法は2つあります。
\nシグナルは非同期に送信することもできます。
\nシグナルを送信するには、Signal.send()、Signal.send_robust()、await Signal.asend()、await Signal.asend_robust() のどれかを呼び出します。引数として sender (ほとんどの場合クラス) を指定する必要があり、他のキーワード引数を好きなだけ指定できます。
たとえば、pizza_done シグナルを送信するには、次のようにします:
class PizzaStore:\n ...\n\n def send_pizza(self, toppings, size):\n pizza_done.send(sender=self.__class__, toppings=toppings, size=size)\n ...\n4つのメソッドはすべて、呼び出されたレシーバー関数とそのレスポンス値のリストを表すタプルのペア [(receiver, response), ...] のリストを返します。
send() は send_robust() と異なり、レシーバ関数が発生させた例外をどのようにハンド リングするかという点で異なります。 send() はレシーバが発生させた例外をキャッチしません。そのため、エラーが発生してもすべてのレシーバにシグナルが通知されるとは限りません。
send_robust() は Python の Exception クラスに由来するすべてのエラーをキャッチし、すべてのレシーバにシグナルが通知されるようにします。エラーが発生した場合、エラーを発生させたレシーバのタプルのペアにエラーインスタンスが返されます。
トレースバックは send_robust() を呼び出したときに返されるエラーの __traceback__ 属性に存在します。
asend() は send() と似ていますが、await しなければならないコルーチンです:
async def asend_pizza(self, toppings, size):\n await pizza_done.asend(sender=self.__class__, toppings=toppings, size=size)\n ...\nWhether synchronous or asynchronous, receivers will be correctly adapted to\nwhether send() or asend() is used. Synchronous receivers will be\ncalled using sync_to_async() when invoked via asend(). Asynchronous\nreceivers will be called using async_to_sync() when invoked via\nsend(). Similar to the case for middleware,\nthere is a small performance cost to adapting receivers in this way. Note that\nin order to reduce the number of sync/async calling-style switches within a\nsend() or asend() call, the receivers are grouped by whether or not\nthey are async before being called. This means that an asynchronous receiver\nregistered before a synchronous receiver may be executed after the synchronous\nreceiver. In addition, async receivers are executed concurrently using\nasyncio.gather().
非同期のリクエスト/レスポンス・サイクル以外のすべての組み込みシグナルは Signal.send() を使ってディスパッチされます。
シグナルからレシーバーを切断するには Signal.disconnect() を呼び出します。引数は Signal.connect() の説明と同じです。このメソッドは、レシーバが切断された場合は True を、切断されなかった場合は False を返します。sender が <app label>.<model> への遅延参照として渡された場合、このメソッドは常に None を返します。
引数 receiver は、切断する登録済みのレシーバを指定します。レシーバを識別するために dispatch_uid を使用する場合は None を指定します。