Django 2.1

Signals




django

Signals

Django द्वारा भेजे जाने वाले सभी संकेतों की एक सूची। सभी अंतर्निहित सिग्नल send() पद्धति का उपयोग करके भेजे जाते हैं।

यह भी देखें

सिग्नल रजिस्टर करने और सिग्नल प्राप्त करने के तरीके के बारे में जानकारी के लिए सिग्नल डिस्पैचर पर प्रलेखन देखें।

जब उपयोगकर्ता लॉग इन / आउट होता है, तो प्रमाणीकरण ढांचा सिग्नल भेजता है

मॉडल के संकेत

django.db.models.signals मॉड्यूल मॉडल सिस्टम द्वारा भेजे गए संकेतों के एक सेट को परिभाषित करता है।

चेतावनी

इनमें से कई सिग्नल विभिन्न मॉडल विधियों जैसे __init__() या save() द्वारा भेजे जाते हैं जिन्हें आप अपने कोड में ओवरराइड कर सकते हैं।

यदि आप अपने मॉडल पर इन विधियों को ओवरराइड करते हैं, तो आपको इस सिग्नल को भेजने के लिए पैरेंट क्लास के तरीकों को कॉल करना होगा।

ध्यान दें कि Django सिग्नल हैंडलर को डिफ़ॉल्ट रूप से कमजोर संदर्भों के रूप में संग्रहीत करता है, इसलिए यदि आपका हैंडलर एक स्थानीय फ़ंक्शन है, तो यह कचरा एकत्र किया जा सकता है। इसे रोकने के लिए, सिग्नल के connect() कॉल करने पर weak=False पास करें।

ध्यान दें

मॉडल सिग्नल sender मॉडल को उसके पूर्ण अनुप्रयोग लेबल को निर्दिष्ट करके किसी रिसीवर को जोड़ने पर आलसी संदर्भित किया जा सकता है। उदाहरण के लिए, polls आवेदन में परिभाषित एक Answer मॉडल को 'polls.Answer' रूप में संदर्भित किया जा सकता है। परिपत्र आयात निर्भरता और स्वैपेबल मॉडल के साथ काम करते समय इस तरह का संदर्भ काफी आसान हो सकता है।

pre_init

django.db.models.signals.pre_init

जब भी आप एक Django मॉडल को __init__() करते हैं, तो यह सिग्नल मॉडल की __init__() विधि की शुरुआत में भेजा जाता है।

इस संकेत के साथ भेजे गए तर्क:

sender
मॉडल वर्ग जो सिर्फ एक उदाहरण था।
args
स्थिति संबंधी तर्कों की एक सूची __init__() :
kwargs
__init__() को __init__() गए कीवर्ड तर्कों का शब्दकोश:

उदाहरण के लिए, tutorial में यह रेखा है:

p = Poll(question="What's up?", pub_date=datetime.now())

pre_init हैंडलर को भेजे गए तर्क होंगे:

तर्क मूल्य
sender Poll (स्वयं कक्षा)
args [] (एक खाली सूची क्योंकि __init__() लिए कोई __init__() तर्क पारित नहीं हुए थे)
kwargs {'question': "What's up?", 'pub_date': datetime.now()}

post_init

django.db.models.signals.post_init

प्री_इनिट की तरह, लेकिन यह तब भेजा जाता है जब __init__() विधि समाप्त हो जाती है।

इस संकेत के साथ भेजे गए तर्क:

sender
जैसा कि ऊपर: मॉडल वर्ग है कि सिर्फ एक उदाहरण बनाया गया था।
instance
मॉडल का वास्तविक उदाहरण जो अभी बनाया गया है।

pre_save

django.db.models.signals.pre_save

यह एक मॉडल की save() विधि की शुरुआत में भेजा जाता है।

इस संकेत के साथ भेजे गए तर्क:

sender
मॉडल वर्ग।
instance
वास्तविक उदाहरण सहेजा जा रहा है।
raw
एक बूलियन; True है कि मॉडल को बिल्कुल प्रस्तुत के रूप में सहेजा गया है (यानी जब एक लोडिंग लोड हो रहा है)। डेटाबेस में अन्य रिकॉर्ड को क्वेरी / संशोधित नहीं करना चाहिए क्योंकि डेटाबेस अभी तक सुसंगत स्थिति में नहीं हो सकता है।
using
डेटाबेस का उपयोग किया जा रहा है।
update_fields
अपडेट करने के लिए फ़ील्ड का सेट save() , या None अगर update_fields को save() लिए पारित नहीं किया गया था save()

post_save

django.db.models.signals.post_save

pre_save तरह, लेकिन save() विधि के अंत में भेजा गया।

इस संकेत के साथ भेजे गए तर्क:

sender
मॉडल वर्ग।
instance
वास्तविक उदाहरण सहेजा जा रहा है।
created
एक बूलियन; True अगर एक नया रिकॉर्ड बनाया गया था।
raw
एक बूलियन; True है कि मॉडल को बिल्कुल प्रस्तुत के रूप में सहेजा गया है (यानी जब एक लोडिंग लोड हो रहा है)। डेटाबेस में अन्य रिकॉर्ड को क्वेरी / संशोधित नहीं करना चाहिए क्योंकि डेटाबेस अभी तक सुसंगत स्थिति में नहीं हो सकता है।
using
डेटाबेस का उपयोग किया जा रहा है।
update_fields
अपडेट करने के लिए फ़ील्ड का सेट save() , या None अगर update_fields को save() लिए पारित नहीं किया गया था save()

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 एक मॉडल उदाहरण पर बदल दिया है। कड़ाई से बोलें, तो यह एक मॉडल सिग्नल नहीं है क्योंकि इसे pre_save द्वारा भेजा गया है, लेकिन चूंकि यह pre_delete / post_delete और pre_delete / post_delete पूरक ManyToManyField , जब यह मॉडल में परिवर्तन की बात करता है, तो यह यहां शामिल है।

इस संकेत के साथ भेजे गए तर्क:

sender
ManyToManyField का वर्णन करने वाला मध्यवर्ती मॉडल वर्ग। कई-से-कई फ़ील्ड परिभाषित होने पर यह क्लास अपने आप बन जाती है; आप इसे कई-से-कई फ़ील्ड पर विशेषता के through एक्सेस कर सकते हैं।
instance
वह उदाहरण जिसके कई-से-कई संबंध अपडेट किए जाते हैं। यह sender का एक उदाहरण हो सकता है, या जिस कक्षा में ManyToManyField संबंधित है।
action

एक स्ट्रिंग जो संबंध पर किए गए अद्यतन के प्रकार को दर्शाता है। यह निम्नलिखित में से एक हो सकता है:

"pre_add"
संबंध में एक या एक से अधिक वस्तुओं को जोड़ने से पहले भेजा जाता है।
"post_add"
एक या एक से अधिक वस्तुओं को संबंध में जोड़ने के बाद भेजा जाता है।
"pre_remove"
एक या एक से अधिक वस्तुओं को रिश्ते से हटा दिया जाता है।
"post_remove"
एक या एक से अधिक वस्तुओं को संबंध से हटाने के बाद भेजा जाता है।
"pre_clear"
संबंध साफ़ होने से पहले भेजा गया।
"post_clear"
रिलेशन क्लियर होने के बाद भेजा जाता है।
reverse
इंगित करता है कि संबंध के किस पक्ष को अपडेट किया गया है (अर्थात, यदि यह आगे या रिवर्स संबंध है जिसे संशोधित किया जा रहा है)।
model
जिन वस्तुओं को जोड़ा जाता है, उनके वर्ग को संबंध से हटा दिया जाता है या हटा दिया जाता है।
pk_set

pre_add , post_add , pre_remove और post_remove क्रियाओं के लिए, यह प्राथमिक कुंजी मानों का एक सेट है, जो संबंध से जोड़ा या हटा दिया गया है।

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 (मध्यवर्ती Pizza.toppings.through वर्ग)
instance p ( Pizza उदाहरण संशोधित किया जा रहा है)
action "pre_add" ( "pre_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 (मध्यवर्ती Pizza.toppings.through वर्ग)
instance t ( Topping उदाहरण संशोधित किया जा रहा है)
action "pre_remove" ( "pre_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- django-admin द्वारा भेजे गए संकेत।

pre_migrate

django.db.models.signals.pre_migrate

किसी एप्लिकेशन को इंस्टॉल करने से पहले migrate कमांड द्वारा भेजा गया। यह उन अनुप्रयोगों के लिए उत्सर्जित नहीं होता है जिनमें एक models मॉड्यूल की कमी होती है।

इस संकेत के साथ भेजे गए तर्क:

sender
माइग्रेट / सिंक किए जाने वाले एप्लिकेशन के लिए एक AppConfig उदाहरण।
app_config
sender रूप में भी।
verbosity

इंगित करता है कि स्क्रीन पर कितने प्रबंधन को प्रबंधित किया जा रहा है। विवरण के लिए --verbosity ध्वज देखें।

pre_migrate लिए सुनने वाले pre_migrate को समायोजित करना चाहिए कि वे इस तर्क के मूल्य के आधार पर स्क्रीन पर क्या आउटपुट करते हैं।

interactive

यदि interactive True , तो उपयोगकर्ता को कमांड लाइन पर चीजों को इनपुट करने के लिए संकेत देना सुरक्षित है। यदि interactive False , तो इस संकेत के लिए काम करने वाले कार्यों को किसी भी चीज के लिए संकेत देने की कोशिश नहीं करनी चाहिए।

उदाहरण के लिए, django.contrib.auth ऐप केवल तभी django.contrib.auth बनाने का संकेत देता है जब interactive True

using
डेटाबेस का उपनाम जिस पर एक कमांड संचालित होगा।
plan
माइग्रेशन योजना जो माइग्रेशन रन के लिए उपयोग की जाने वाली है। जबकि योजना सार्वजनिक एपीआई नहीं है, यह दुर्लभ मामलों के लिए अनुमति देता है जब योजना को जानना आवश्यक होता है। एक योजना दो-टुपल्स की एक सूची है जिसमें पहला आइटम माइग्रेशन क्लास का उदाहरण है और दूसरा आइटम दिखा रहा है कि क्या माइग्रेशन वापस रोल किया गया था ( True ) या लागू ( False )।
apps
माइग्रेशन चलने से पहले प्रोजेक्ट की स्थिति वाले Apps का एक उदाहरण। इसका उपयोग वैश्विक apps रजिस्ट्री के बजाय उन मॉडलों को पुनर्प्राप्त करने के लिए किया जाना चाहिए, जिन पर आप ऑपरेशन करना चाहते हैं।

post_migrate

django.db.models.signals.post_migrate

migrate के अंत में भेजे गए (भले ही कोई माइग्रेशन न चला हो) और flush कमांड। यह उन अनुप्रयोगों के लिए उत्सर्जित नहीं होता है जिनमें एक models मॉड्यूल की कमी होती है।

इस संकेत के संचालकों को डेटाबेस स्कीमा परिवर्तन नहीं करना चाहिए क्योंकि ऐसा करने से flush कमांड विफल हो सकता है यदि यह migrate कमांड के दौरान चलता है।

इस संकेत के साथ भेजे गए तर्क:

sender
अनुप्रयोग के लिए एक AppConfig उदाहरण जो अभी स्थापित किया गया था।
app_config
sender रूप में भी।
verbosity

इंगित करता है कि स्क्रीन पर कितने प्रबंधन को प्रबंधित किया जा रहा है। विवरण के लिए --verbosity ध्वज देखें।

कार्य जो post_migrate लिए post_migrate , उन्हें इस तर्क के मूल्य के आधार पर स्क्रीन पर आउटपुट को समायोजित करना चाहिए।

interactive

यदि interactive True , तो उपयोगकर्ता को कमांड लाइन पर चीजों को इनपुट करने के लिए संकेत देना सुरक्षित है। यदि interactive False , तो इस संकेत के लिए काम करने वाले कार्यों को किसी भी चीज के लिए संकेत देने की कोशिश नहीं करनी चाहिए।

उदाहरण के लिए, django.contrib.auth ऐप केवल तभी django.contrib.auth बनाने का संकेत देता है जब interactive True

using
डेटाबेस उर्फ ​​सिंक्रनाइज़ेशन के लिए उपयोग किया जाता है। डिफ़ॉल्ट डेटाबेस में default
plan
माइग्रेशन योजना जो माइग्रेशन रन के लिए उपयोग की गई थी। जबकि योजना सार्वजनिक एपीआई नहीं है, यह दुर्लभ मामलों के लिए अनुमति देता है जब योजना को जानना आवश्यक होता है। एक योजना दो-टुपल्स की एक सूची है जिसमें पहला आइटम माइग्रेशन क्लास का उदाहरण है और दूसरा आइटम दिखा रहा है कि क्या माइग्रेशन वापस रोल किया गया था ( 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 उदाहरण प्रदान करते हैं, तो कृपया सुनिश्चित करें कि संकेत AppConfig.ready() में पंजीकृत है। AppConfig s को उन परीक्षणों के लिए फिर से बनाया जाता है जो 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

जब भी Django आने वाले HTTP अनुरोध को संसाधित करते समय एक अपवाद का सामना करता है, तो यह संकेत भेजा जाता है।

इस संकेत के साथ भेजे गए तर्क:

sender
ऊपर के रूप में हैंडलर वर्ग।
request
HttpRequest ऑब्जेक्ट।

परीक्षण संकेत

परीक्षण चलाने पर केवल संकेत भेजे गए।

setting_changed

django.test.signals.setting_changed

जब django.test.TestCase.settings() संदर्भ प्रबंधक या django.test.override_settings() डेकोरेटर / संदर्भ प्रबंधक के माध्यम से सेटिंग का मान बदला जाता है, तो यह संकेत भेजा जाता है।

यह वास्तव में दो बार भेजा जाता है: जब नया मूल्य लागू किया जाता है ("सेटअप") और जब मूल मूल्य बहाल होता है ("फाड़")। दोनों के बीच अंतर करने के लिए enter तर्क का उपयोग करें।

आप गैर-परीक्षण स्थितियों में django.test से आयात करने से बचने के लिए django.core.signals से भी इस संकेत को आयात कर सकते हैं।

इस संकेत के साथ भेजे गए तर्क:

sender
सेटिंग्स हैंडलर।
setting
सेटिंग का नाम।
value
परिवर्तन के बाद सेटिंग का मूल्य। ऐसी सेटिंग्स के लिए जो शुरू में मौजूद नहीं हैं, "फाड़" चरण में, 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
डेटाबेस कनेक्शन जो खोला गया था। इसका उपयोग कई डेटाबेस में विभिन्न डेटाबेस से कनेक्शन संकेतों को अलग करने के लिए किया जा सकता है।