最近、NodeJS などの他のフレームワークで遊んでいます。
応答を返す可能性があり、さらに操作を行うことができる点が気に入っています。
例えば
def view(request):
do_something()
return HttpResponse()
do_more_stuff() #not possible!!!
Django は、リクエストを返した後に操作を実行する方法を既に提供しているかもしれません。
助けていただければ幸いです。=D
最近、NodeJS などの他のフレームワークで遊んでいます。
応答を返す可能性があり、さらに操作を行うことができる点が気に入っています。
例えば
def view(request):
do_something()
return HttpResponse()
do_more_stuff() #not possible!!!
Django は、リクエストを返した後に操作を実行する方法を既に提供しているかもしれません。
助けていただければ幸いです。=D
メソッドからすでに戻っているので、そのままではありません。タスクをキューに渡し、http 要求/応答フローの外で実行するCeleryのようなものを使用できます。do_more_stuff
do_more_stuff()
関数から戻っているため、do_more_stuff が呼び出されることはありません。
ロスが提案するように、戻る前に何かをキューに入れる重労働を検討している場合(セロリの場合は+1)。
ただし、コンテンツを返すことを検討している場合は、何かを実行してより多くのコンテンツをユーザー ストリーミングに返すことが、おそらく探しているものです。イテレーターまたはジェネレーターを HttpResponse に渡すことができます。これにより、反復処理が行われ、コンテンツが少しずつプッシュされます。少し不自然に感じますが、発電機のロックスターなら、さまざまな状態で目的を達成するのに十分なことができるかもしれません。
または、django ビューへのイベントの発生、ビューからのデータの読み取りなど、必要なことを行うために多くの ajax を使用するようにページを再設計することもできると思います。
それは、非同期の負担がどこにあるのか、つまりクライアント、サーバー、または応答に帰着します。
私はまだnode.jsに精通していませんが、あなたが話しているユースケースを見るのは興味深いでしょう.
編集:シグナルをもう少し調べましたが、それらはプロセスで発生しますが、リクエストがdjangoによって処理された後にrequest_finishedのシグナルが組み込まれていますが、これは特定のものよりもキャッチオールです。