لیستی از تمام سیگنال هایی که Django ارسال می کند. تمام سیگنال های داخلی با استفاده از روش Send () ارسال می شوند.

برای اطلاعات در مورد نحوه ثبت نام و دریافت سیگنال ، به اسناد مربوط به توزیع کننده سیگنال مراجعه کنید.

سیگنال های مدل

ماژول django. db. models. signals مجموعه ای از سیگنال های ارسال شده توسط سیستم مدل را تعریف می کند.

بسیاری از این سیگنال ها توسط روش های مختلف مدل مانند __init __ () یا ذخیره () ارسال می شوند که می توانید در کد خود غلبه کنید.

اگر این روش ها را بر روی مدل خود نادیده بگیرید ، باید با روش های کلاس والدین تماس بگیرید تا این سیگنال ها ارسال شوند.

توجه داشته باشید که Django به طور پیش فرض دستگیرندگان سیگنال را به عنوان منابع ضعیف ذخیره می کند ، بنابراین اگر کنترل کننده شما یک عملکرد محلی باشد ، ممکن است زباله جمع آوری شود. برای جلوگیری از این امر ، هنگام تماس با اتصال سیگنال () ضعیف = نادرست را عبور دهید.

مدل ارسال کننده سیگنال های مدل می تواند هنگام اتصال یک گیرنده با مشخص کردن برچسب برنامه کامل آن ، تنبل شود. به عنوان مثال ، یک مدل سؤال تعریف شده در برنامه نظرسنجی ها می تواند به عنوان "نظرسنجی" ارجاع شود. این نوع مرجع می تواند هنگام برخورد با وابستگی های وارداتی و مدلهای قابل تعویض کاملاً مفید باشد.

pre_init

هر وقت یک مدل جنگو را فوری می کنید ، این سیگنال در ابتدای روش __init __ () مدل ارسال می شود.

استدلال های ارسال شده با این سیگنال:

Sender کلاس مدل که فقط نمونه ای ایجاد کرده است. لیستی از استدلال های موقعیتی را که به __init __ () منتقل شده است ، استدلال می کند. Kwargs یک فرهنگ لغت از استدلال های کلمات کلیدی به __init __ () منتقل شد.

به عنوان مثال ، این آموزش دارای این خط است:

استدلال های ارسال شده به یک کنترل کننده pre_init این خواهد بود:

post_init

مانند pre_init ، اما این یکی با اتمام روش __init __ () ارسال می شود.

استدلال های ارسال شده با این سیگنال:

فرستنده همانطور که در بالا: کلاس مدل که فقط نمونه ای ایجاد کرده بود. نمونه، مثال

نمونه واقعی مدلی که تازه ایجاد شده است.

به عنوان مثال . _ستات قبل از ارسال سیگنال post_init تنظیم نشده است ، بنابراین ویژگی های _state همیشه مقادیر پیش فرض خود را دارند. به عنوان مثال ، _state. db هیچ کدام نیست.

به دلایل عملکرد ، شما نباید در گیرنده های سیگنال های pre_init یا post_init نمایش داده شود زیرا آنها برای هر نمونه ای که در هنگام تکرار پرس و جو انجام می شود ، اجرا می شوند.

pre_save

این در ابتدای روش ذخیره () یک مدل ارسال می شود.

استدلال های ارسال شده با این سیگنال:

فرستنده کلاس مدل. instance نمونه واقعی در حال ذخیره شدن. خام A Boolean; درست است اگر مدل دقیقاً همانطور که ارائه شده ذخیره شود (یعنی هنگام بارگیری یک فیکسچر). نباید سایر رکوردهای پایگاه داده را پرس و جو کرد/تغییر داد زیرا ممکن است پایگاه داده هنوز در وضعیت ثابتی قرار نداشته باشد. با استفاده از نام مستعار پایگاه داده استفاده می شود. update_fields مجموعه ای از فیلدهایی که باید به عنوان ارسال به Model. save() یا None در صورتی که update_fields به save() منتقل نمی شود، به روزرسانی می شود.

post_save ¶

مانند pre_save، اما در انتهای متد save() ارسال شد.

استدلال های ارسال شده با این سیگنال:

فرستنده کلاس مدل. instance نمونه واقعی در حال ذخیره شدن. یک بولی ایجاد کرد. درست است اگر رکورد جدیدی ایجاد شود. خام A Boolean; درست است اگر مدل دقیقاً همانطور که ارائه شده ذخیره شود (یعنی هنگام بارگیری یک فیکسچر). نباید سایر رکوردهای پایگاه داده را پرس و جو کرد/تغییر داد زیرا ممکن است پایگاه داده هنوز در وضعیت ثابتی قرار نداشته باشد. با استفاده از نام مستعار پایگاه داده استفاده می شود. update_fields مجموعه ای از فیلدهایی که باید به عنوان ارسال به Model. save() یا None در صورتی که update_fields به save() منتقل نمی شود، به روزرسانی می شود.

پیش_حذف ¶

در ابتدای متد delete() مدل و متد delete() queryset ارسال می شود.

استدلال های ارسال شده با این سیگنال:

فرستنده کلاس مدل. instance نمونه واقعی در حال حذف. با استفاده از نام مستعار پایگاه داده استفاده می شود.

پست_حذف ¶

مانند pre_delete، اما در پایان متد delete() مدل و متد delete() queryset ارسال می شود.

استدلال های ارسال شده با این سیگنال:

فرستنده کلاس مدل. نمونه، مثال

نمونه واقعی در حال حذف شدن است.

توجه داشته باشید که شی دیگر در پایگاه داده نخواهد بود، بنابراین بسیار مراقب باشید که با این نمونه چه کاری انجام می دهید.

با استفاده از نام مستعار پایگاه داده استفاده می شود.

m2m_changed ¶

هنگامی که یک ManyToManyField در یک نمونه مدل تغییر می کند، ارسال می شود. به طور دقیق، این یک سیگنال مدل نیست زیرا توسط ManyToManyField ارسال می شود، اما از آنجایی که مکمل pre_save / post_save و pre_delete / post_delete در مورد ردیابی تغییرات مدل ها است، در اینجا گنجانده شده است.

استدلال های ارسال شده با این سیگنال:

فرستنده کلاس مدل میانی که ManyToManyField را توصیف می کند. این کلاس به طور خودکار زمانی که یک فیلد چند به چند تعریف می شود ایجاد می شود. می توانید با استفاده از ویژگی through در فیلد many-to-many به آن دسترسی داشته باشید. instance نمونه ای که رابطه چند به چند آن به روز می شود. این می تواند نمونه ای از فرستنده یا کلاسی باشد که ManyToManyField به آن مربوط است. عمل

رشته ای که نشان دهنده نوع به روز رسانی است که روی رابطه انجام می شود. این می تواند یکی از موارد زیر باشد:

"pre_add" ارسال شده قبل از اضافه شدن یک یا چند شی به رابطه."post_add" ارسال شده پس از یک یا چند شیء به رابطه اضافه می شود."pre_remove" ارسال شده قبل از حذف یک یا چند شی از رابطه."post_remove" ارسال شده پس از یک یا چند شیء از رابطه حذف می شوند."pre_clear" ارسال شده قبل از پاک شدن رابطه."post_clear" ارسال شده پس از پاک شدن رابطه. معکوس نشان می دهد که طرف رابطه به روز شده است (یعنی اگر این رابطه رو به جلو یا معکوس است که اصلاح می شود). کلاس اشیاء اضافه شده به آن را از این رابطه حذف کرده یا از آن پاک کنید. pk_set

برای اقدامات PRE_ADD و POST_ADD ، این مجموعه ای از مقادیر اصلی کلیدی است که به این رابطه اضافه شده یا به آن اضافه شده است. این ممکن است زیر مجموعه ای از مقادیر ارسال شده برای افزودن باشد ، زیرا درج ها باید مقادیر موجود را فیلتر کنند تا از یک EntaryError پایگاه داده جلوگیری شود.

برای اقدامات premove و post_remove ، این مجموعه ای از مقادیر اصلی کلیدی است که ارسال شده است تا از این رابطه حذف شود. این بستگی به این ندارد که آیا مقادیر در واقع حذف شده یا حذف شده اند. به طور خاص ، مقادیر غیر موجود ممکن است ارسال شود و در PK_SET ظاهر می شود ، حتی اگر هیچ تاثیری در پایگاه داده نداشته باشد.

برای اقدامات pre_clear و post_clear ، این هیچ کدام نیست.

با استفاده از نام مستعار پایگاه داده استفاده می شود.

به عنوان مثال ، اگر یک پیتزا می تواند چندین اشیاء تاپ را داشته باشد ، مانند این مدل شده است:

اگر ما یک کنترل کننده مانند این را وصل کنیم:

و سپس چنین کاری انجام داد:

آرگومان های ارسال شده به یک کنترل کننده M2M_CHANGED (Toppings_Changed در مثال بالا) عبارتند از:

و اگر ما چنین کاری انجام می دادیم:

استدلال های ارسال شده به یک کنترل کننده M2M_CHANGED عبارتند از:

class_preped

هر زمان که یک کلاس مدل "آماده شده" ارسال شده است - یعنی هنگامی که مدل تعریف شده و با سیستم مدل Django ثبت شده است. جنگو از این سیگنال داخلی استفاده می کند. این به طور کلی در برنامه های شخص ثالث مورد استفاده قرار نمی گیرد.

از آنجا که این سیگنال در طی فرآیند جمعیت رجیستری برنامه ارسال می شود ، و AppConfig. Ready () پس از جمع شدن برنامه APP به طور کامل اجرا می شود ، گیرنده ها نمی توانند در این روش وصل شوند. یک احتمال این است که آنها را AppConfig متصل کنید . __ init __ () در عوض ، مراقبت از عدم وارد کردن مدل ها یا ایجاد تماس به رجیستری برنامه.

استدلالهایی که با این سیگنال ارسال می شوند:

Sender کلاس مدل که تازه تهیه شده است.

سیگنال های مدیریت

pre_migrate

قبل از شروع نصب برنامه توسط دستور مهاجرت ارسال شده است. برای برنامه هایی که فاقد ماژول مدل هستند ، منتشر نمی شود.

استدلال های ارسال شده با این سیگنال:

فرستنده نمونه AppConfig برای برنامه در حال انتقال/همگام سازی. app_config همان فرستنده. فساد

نشان می دهد که چه میزان اطلاعات مدیریت . Py در حال چاپ روی صفحه است. برای جزئیات بیشتر به پرچ م-سنگریزی مراجعه کنید.

توابع گوش دادن به pre_migrate باید بر اساس مقدار این آرگومان ، آنچه را که آنها را بر روی صفحه نمایش می دهند تنظیم کنند.

اگر تعاملی صحیح باشد ، ایمن است که کاربر را مجبور به وارد کردن موارد در خط فرمان کند. اگر تعاملی نادرست باشد ، توابعی که به این سیگنال گوش می دهند نباید سعی در هر چیزی داشته باشند.

به عنوان مثال ، برنامه django. contrib. auth فقط در صورت صحیح بودن تعاملی باعث ایجاد یک سوپریزر می شود.

با استفاده از نام مستعار پایگاه داده که یک دستور در آن کار خواهد کرد. برنامه مهاجرت را که برای اجرای مهاجرت استفاده می شود ، برنامه ریزی کنید. در حالی که این طرح API عمومی نیست ، اما این امکان را برای موارد نادر در صورت لزوم دانستن این طرح فراهم می کند. یک برنامه لیستی از دو نوع است که مورد اول نمونه کلاس مهاجرت است و مورد دوم که نشان می دهد مهاجرت به عقب (درست) یا اعمال شده (نادرست) نشان داده شده است. برنامه هایی از برنامه های حاوی وضعیت پروژه قبل از اجرای مهاجرت. برای بازیابی مدلهایی که می خواهید در آنها انجام دهید ، باید به جای رجیستری برنامه های جهانی استفاده شود.

post_migrate

ارسال شده در پایان مهاجرت (حتی اگر هیچ مهاجرتی اجرا نشود) و دستورات گرگرفتگی. برای برنامه هایی که فاقد ماژول مدل هستند ، منتشر نمی شود.

دستگیرندگان این سیگنال نباید تغییرات طرحواره پایگاه داده را انجام دهند زیرا انجام این کار ممکن است باعث شود که در صورت اجرای دستور مهاجرت ، دستور Flush شکست بخورد.

استدلال های ارسال شده با این سیگنال:

Sender یک نمونه AppConfig برای برنامه ای که تازه نصب شده است. app_config همان فرستنده. فساد

نشان می دهد که چه میزان اطلاعات مدیریت . Py در حال چاپ روی صفحه است. برای جزئیات بیشتر به پرچ م-سنگریزی مراجعه کنید.

توابع گوش دادن به post_migrate باید بر اساس مقدار این آرگومان ، آنچه را که آنها را به صفحه منتقل می کنند ، تنظیم کنند.

اگر تعاملی صحیح باشد ، ایمن است که کاربر را مجبور به وارد کردن موارد در خط فرمان کند. اگر تعاملی نادرست باشد ، توابعی که به این سیگنال گوش می دهند نباید سعی در هر چیزی داشته باشند.

به عنوان مثال ، برنامه django. contrib. auth فقط در صورت صحیح بودن تعاملی باعث ایجاد یک سوپریزر می شود.

با استفاده از پایگاه داده نام مستعار مورد استفاده برای هماهنگ سازی. پیش فرض به پایگاه داده پیش فرض. برنامه مهاجرت را که برای اجرای مهاجرت استفاده شده است ، برنامه ریزی کنید. در حالی که این طرح API عمومی نیست ، اما این امکان را برای موارد نادر در صورت لزوم دانستن این طرح فراهم می کند. یک برنامه لیستی از دو نوع است که مورد اول نمونه کلاس مهاجرت است و مورد دوم که نشان می دهد مهاجرت به عقب (درست) یا اعمال شده (نادرست) نشان داده شده است. برنامه هایی از برنامه های حاوی وضعیت پروژه پس از اجرای مهاجرت. برای بازیابی مدلهایی که می خواهید در آنها انجام دهید ، باید به جای رجیستری برنامه های جهانی استفاده شود.

به عنوان مثال ، شما می توانید یک تماس تلفنی را در یک AppConfig مانند این ثبت کنید:

اگر یک نمونه AppConfig را به عنوان آرگومان فرستنده ارائه می دهید ، لطفاً اطمینان حاصل کنید که سیگنال در Ready () ثبت شده است. AppConfig S برای تست هایی که با یک مجموعه اصلاح شده از نصب_پ (مانند تنظیمات ناعادلانه) اجرا می شوند ، بازسازی می شوند و چنین سیگنالهایی باید برای هر نمونه جدید AppConfig متصل شوند.

سیگنال های درخواست/پاسخ

سیگنال های ارسال شده توسط چارچوب اصلی هنگام پردازش درخواست.

Request_started

ارسال شده هنگامی که Django شروع به پردازش درخواست HTTP می کند.

استدلال های ارسال شده با این سیگنال:

Sender the Handler - به عنوان مثالdjango. core. handlers. wsgi. wsgihandler - این درخواست را انجام داد. فرهنگ لغت محیط ارائه شده به درخواست را محیط زیست.

درخواست_

هنگامی که Django با ارائه پاسخ HTTP به مشتری ، ارسال شد.

استدلال های ارسال شده با این سیگنال:

کلاس کنترل کننده ، مانند بالا.

got_request_exception

این سیگنال هر زمان که Django هنگام پردازش یک درخواست HTTP ورودی با استثناء روبرو می شود ، ارسال می شود.

استدلال های ارسال شده با این سیگنال:

فرستنده بلااستفاده (همیشه هیچ). درخواست HTTPREQUEST Object.

سیگنال های آزمایش

سیگنال ها فقط هنگام اجرای تست ارسال می شوند.

setting_changed

این سیگنال هنگامی ارسال می شود که مقدار یک تنظیم از طریق مدیر متن django. test. testcase. settings () یا مدیر django. test. override_settings () دکوراسیون/مدیر زمینه تغییر یابد.

این در واقع دو بار ارسال می شود: وقتی مقدار جدید اعمال می شود ("تنظیم") و هنگامی که مقدار اصلی ترمیم می شود ("Teardown"). برای تمایز بین این دو از آرگومان Enter استفاده کنید.

همچنین می توانید این سیگنال را از django. core. signals وارد کنید تا از واردات از django. test در شرایط غیر آزمون جلوگیری کنید.

استدلال های ارسال شده با این سیگنال:

فرستنده تنظیم کننده تنظیمات. تنظیم نام تنظیم. مقدار تنظیم را پس از تغییر ارزش دهید. برای تنظیماتی که در ابتدا وجود ندارند ، در مرحله "Teardown" ، ارزش هیچ کدام نیست. وارد یک بولی شوید. اگر تنظیمات اعمال شود ، در صورت ترمیم درست است.

template_rendered

ارسال شده هنگامی که سیستم آزمایش یک الگوی را ارائه می دهد. این سیگنال در حین عملکرد عادی یک سرور Django ساطع نمی شود - فقط در طول آزمایش در دسترس است.

استدلال های ارسال شده با این سیگنال:

فرستنده شیء الگوی ارائه شده. الگوی همان متن فرستنده ، زمینه ای که الگوی آن ارائه شده است.

بسته بندی های پایگاه داده ¶

سیگنال های ارسال شده توسط بسته بندی پایگاه داده هنگام اتصال پایگاه داده.

Coection_Created

ارسال شده هنگامی که بسته بندی پایگاه داده اتصال اولیه به پایگاه داده را ایجاد می کند. این امر به ویژه در صورت تمایل به ارسال هرگونه دستور اتصال پست به Backend SQL مفید است.

استدلال های ارسال شده با این سیگنال:

Sender کلاس بسته بندی پایگاه داده - یعنی django. db. backends. postgresql. databasewrapper یا django. db. backends. mysql. databasewrapper و غیره. اتصال پایگاه داده ای که باز شده است. این می تواند در یک پیکربندی چند داده برای تمایز سیگنال های اتصال از پایگاه داده های مختلف استفاده شود.

اطلاعات اضافی

پشتیبانی از Django!

• فلیپه کلرمن برای حمایت از توسعه جنگو به بنیاد نرم افزار Django اهدا کرد. امروز اهدا کنید!

فهرست

مرور کردن

• قبلی: تنظیمات
• بعدی: قالب ها

تو اینجایی:

کمک گرفتن

سؤالات متداول سؤالات متداول را امتحان کنید - این به بسیاری از سؤالات متداول پاسخ می دهد. فهرست ، فهرست ماژول یا فهرست مطالب مفید هنگام جستجوی اطلاعات خاص. لیست پستی کاربر Django برای جستجوی اطلاعات در بایگانی لیست پستی Django-USERS یا ارسال یک سؤال. کانال #Django IRC سوالی را در کانال #Django IRC سؤال کنید ، یا گزارش های IRC را جستجو کنید تا ببینید که آیا قبلاً از آن سؤال شده است یا خیر. سرور Django Discord به انجمن Django Discord بپیوندید. انجمن رسمی جنگو در انجمن Django به جامعه بپیوندید. گزارش ردیاب بلیط اشکالات با مستندات Django یا Django در ردیاب بلیط ما.