हमें Django स्वाद उत्तेजित करता है और आकर्षित करता है

Django के संस्करण 3 की आधिकारिक रिलीज के कई हफ्ते हो चुके हैं। मैंने आधिकारिक रिलीज के प्रकाशन से पहले ही इस संस्करण के साथ काम किया और दुर्भाग्य से, मैंने देखा कि Django का विकास काफी धीमा हो गया। संस्करण 1.3 कई बार 1.7 से भिन्न होता है, लेकिन संस्करण 3 में शाखा 2 में कॉस्मेटिक परिवर्तन शामिल हैं और अधिक नहीं।

मेरा वाइनपैड प्रोजेक्ट Django 1.3 के साथ शुरू हुआ, और अब तक यह Django के आंतरिक कोड के लगभग 12% को फिर से परिभाषित कर चुका है।

नए संस्करण के लिए कोड को देखकर, मैं समझता हूं कि पिछले संस्करणों के साथ काम करते समय मैं या मेरे सहयोगियों द्वारा किए गए संपादन और आगे बढ़ेंगे। लेकिन रोडमैप और आधिकारिक रिपॉजिटरी में धीमे बदलाव को देखते हुए, हमें भविष्य के संस्करणों में त्रुटियों को ठीक करने के लिए इंतजार नहीं करना होगा।

यह मैं कीड़े पर काम करने के बारे में बात करना चाहता हूं:

विधि प्राप्त करें

कुछ लोगों को एहसास है कि शुरू से ही मानक प्राप्त django विधि में एक त्रुटि थी। प्राप्त विधि को या तो एक वस्तु को आपको वापस करना चाहिए, या चेतावनी देना चाहिए कि कई वस्तुएं मिलीं, या रिपोर्ट करें कि कोई वस्तु नहीं है।

1 def get(self, *args, **kwargs): 2 clone = self._chain() if self.query.combinator else self.filter(*args, **kwargs) 3 if self.query.can_filter() and not self.query.distinct_fields: 4 clone = clone.order_by() 5 limit = None 6 if not clone.query.select_for_update or connections[clone.db].features.supports_select_for_update_with_limit: 7 limit = MAX_GET_RESULTS 8 clone.query.set_limits(high=limit) 9 num = len(clone) 10 if num == 1: 11 return clone._result_cache[0] 12 if not num: 13 raise self.model.DoesNotExist() 14 raise self.model.MultipleObjectsReturned() 

पंक्ति 9 उन सभी रिकॉर्डों का डेटा प्राप्त करती है जो क्वेरीसेट में निर्दिष्ट होते हैं और उन्हें ऑब्जेक्ट के एक सेट में अनुवाद करते हैं। प्रलेखन में इसके बारे में एक चेतावनी है।

संस्करण 3 से पहले, अनुरोधित वस्तुओं की संख्या पर कोई सीमा नहीं थी। इसका मतलब है कि पूरी तरह से सभी डेटा प्राप्त करें और उन्हें वस्तुओं में बदल दिया, चेतावनी देने से पहले कि बहुत सारी वस्तुएं हैं।

परिणामस्वरूप, आपको मेमोरी में कई मिलियन ऑब्जेक्ट मिल सकते हैं, केवल यह पता लगाने के लिए कि 1 से अधिक ऑब्जेक्ट मिला। अब लाइनें 5,7,8 हैं। और अब आप गर्व से केवल MAX_GET_RESULTS = 21 ऑब्जेक्ट प्राप्त करने से पहले जानते हैं कि 1 से अधिक ऑब्जेक्ट हैं।
भारी "__init__" के साथ देरी महत्वपूर्ण होगी। इलाज कैसे करें:
Django.db.models.query.py में MAX_GET_RESULTS ओवरराइड करें
GET के उपयोग से पहले GET या कॉल को ओवरराइड करें:

 vars(queryset.query).update({'high_mark':2, 'low_mark':0})  queryset.query.set_limits(0,2) 

OfInit__ Django मॉडल की विधि

अंतर्निहित विधि में __in__ के कोड में घोषणा पूरी तरह से स्पष्ट नहीं है

 _setattr=setattr 

यह संभवतः स्थानीय शब्दकोश में फ़ंक्शन संदर्भ को स्थानांतरित करके कोड को छद्म-सख्त करने के लिए है, लेकिन यह उस बारे में नहीं है। कई समस्याएं हैं:

1. यदि आप __init__ मॉडल में अतिरिक्त विशेषता = मान जोड़े पास करते हैं, तो आपको "एक अप्रत्याशित कीवर्ड तर्क मिल जाएगा"।

इस मामले में, मैं सुझाव देता हूं कि __init__ पद्धति को बोझ न डालें, लेकिन आरंभीकरण के बाद विशेषताओं को जोड़ने के लिए:

 obj = MyClass() vars(obj).update({'attr':val, 'attr2':val2 ...}) 

2. नए Django ने मॉडल के किसी भी क्षेत्र (Field.descriptor_class) पर वर्णनकर्ताओं को फिर से परिभाषित करने की क्षमता को जोड़ा। लेकिन एक भी विवरणकर्ता यह नहीं जानता है कि ऑब्जेक्ट को इनिशियलाइज़ किया गया है या नहीं। यह आवश्यक है, उदाहरण के लिए, यदि डिस्क्रिप्टर प्रीफ़ैच_रेल्ड ऑब्जेक्ट्स के डेटा का उपयोग करेगा, जो मुख्य ऑब्जेक्ट के आरंभीकरण के बाद ही दिखाई देगा।

मैं आरंभ के अंत के संकेत का उपयोग नहीं करना चाहता, क्योंकि इसमें बहुत सारे ग्राहक हो सकते हैं।

इस मामले में, मैं __init__ को ओवरराइड करने और इनिशियलाइज़ेशन को समाप्त करने के लिए एक विशेषता जोड़कर कुछ भी समझदारी से नहीं आया।

  def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self._end_init = True 

क्वेरीसमूहों

हार्डकोड EmptyQuerySet / DateQuerySet को हटा दिया गया है, यह पहले से ही अच्छा है। हालाँकि, मैं एक वैचारिक रूप से एक प्रबंधक के रूप में क्वेरीसेट वाली स्थिति को पसंद नहीं करता।

यदि मैं प्रबंधकों द्वारा बनाई गई क्वेरीसेट वर्ग को ओवरराइड करना चाहता हूं, तो मैं _queryset_class विशेषता जोड़ता हूं

 class MyManager(models.Manager): _queryset_class = MyQuerySet 

ध्यान दें, पुराने संस्करणों के लिए यह काम नहीं करता है, उदाहरण के लिए, आप यह कर सकते हैं:

 class MyManager(models.Manager): def get_query_set(self): response = super(MyManager, self).get_query_set() response.__class__ = MyQuerySet return response 

इनलाइनफ़ॉर्मसेट व्यवस्थापक पैनल

कई समस्याएं हैं:

1. मानक इनलाइनफ़ॉर्मसेट प्रविष्टियों को प्रदर्शित करना संभव नहीं है जो मुख्य रूप ऑब्जेक्ट के साथ सीधे संवाद नहीं करते हैं। उदाहरण के लिए: उत्पाद की कीमतें संपादित करने के लिए एक फ़ॉर्म। बीच में "समान" सामानों के लिए थोक खरीद मूल्यों का संदर्भ सांख्यिकीय टैबुलिनलाइन रूप निहित है।

यह get_formset इनलाइन मॉडल विधि को ओवरराइड करके और BaseInlineFormSet से विरासत में मिली अपनी खुद की MyFormSet बनाकर हल किया जाता है

 def get_formset(self, request, obj=None, **kwargs): kwargs['formset'] = MyFormSet super().get_formset(request, obj, **kwargs) class MyFormSet(BaseInlineFormSet): pass 

2. यदि आप व्यवस्थापक पैनल में एक इनलाइनफॉर्मसेट के साथ किसी ऑब्जेक्ट को संपादित कर रहे हैं, और इस समय कोई व्यक्ति किसी अन्य तंत्र के माध्यम से इनलाइनफॉर्म के अंदर ऑब्जेक्ट रिकॉर्ड को हटा देगा, तो आपको एक त्रुटि प्राप्त होगी और आप ऑब्जेक्ट को सहेजने में सक्षम नहीं होंगे। केवल एक नई ब्राउज़र विंडो में कोपी पेस्ट के माध्यम से।

मुझे अब तक केवल एक ही समाधान मिला है - इनलाइनफ़ॉर्मसेट का उपयोग न करें।

व्यवस्थापक पैनल

Django की "हत्यारा सुविधा", परियोजना का सबसे बड़ा कैक्टस है:

1. मॉडल प्रशासक में "ऑब्जेक्ट हटाएं" कार्रवाई डिफ़ॉल्ट रूप से दिखाई देती है, इससे कोई फर्क नहीं पड़ता कि उपयोगकर्ता के पास हटाने के अधिकार हैं या नहीं।

यह इस क्रिया को डिफ़ॉल्ट रूप से अक्षम करके हल किया गया है:

 admin.site.disable_action('delete_selected') 

2. व्यवस्थापक पैनल से अतिरिक्त उपयोगकर्ता अधिकार बनाना तब तक संभव नहीं होगा जब तक आप मॉडल व्यवस्थापक को सक्षम नहीं करते हैं।

 from django.contrib.auth.models import Permission class PermissionsAdmin(admin.ModelAdmin): search_fields = ('name', 'codename','content_type__app_label', 'content_type__model') list_display = ('name', 'codename',) actions = None admin.site.register(Permission, PermissionsAdmin) 

3. काश, Django में केवल कुछ वस्तुओं का उपयोग करने का अधिकार मौजूद नहीं है।

इसे विशेष ध्वज के साथ djangoAdminLog में प्रविष्टि लिखकर हल किया जा सकता है।
और फिर ध्वज की जाँच करें:

 user.logentry_set.filter(action_flag=ENABLED, .....).exists() 

4. यदि आप प्रलेखन में वर्णित प्रशासक कार्रवाइयाँ बनाते हैं, तो याद रखें कि वे djangoAdminLog में स्वचालित रूप से लॉग इन नहीं हैं।

5. प्रलेखन के इस भाग का एक और दोष यह है कि सभी उदाहरण केवल कार्यों पर हैं। लेकिन GCBV का क्या? मेरी परियोजनाओं में, मॉडल प्रशासकों के सभी कार्यों को GCBV में स्थानांतरित कर दिया जाता है। भंडार।

कार्रवाई कनेक्शन मानक है:

 class MyAdmin(admin.ModelAdmin): actions = (MyActionBasedOnActionView.as_view(),) 

ContentType - django मॉडल रजिस्ट्री

50% प्रतिभा / 50% नीरसता।
किसी भी मॉडल की डिफ़ॉल्ट मॉडल रजिस्ट्री तक पहुंच नहीं है।
हमारी परियोजनाओं में, सभी वर्गों के लिए एक मिश्रण जोड़कर इसे हल किया जाता है:

 from django.contrib.contenttypes.models import ContentType class ExportMixin(object): @classmethod def ct(cls): if not hasattr(cls, '_ct'): cls._ct, create = ContentType.objects.get_or_create(**cls.get_app_model_dict()) if create: cls._ct.name = cls._ct.model._meta.verbose_name cls._ct.save() return cls._ct @classmethod def get_model_name(cls): if not hasattr(cls, '_model_name'): cls._model_name = cls.__name__.lower() return cls._model_name @classmethod def get_app_name(cls): if not hasattr(cls, '_app_name'): cls._app_name = cls._meta.app_label.lower() return cls._app_name @classmethod def get_app_model_dict(cls): if not hasattr(cls, '_format_kwargs'): cls._format_kwargs = {'app_label': cls.get_app_name(), 'model': cls.get_model_name()} return cls._format_kwargs 

अब हम यदि आवश्यक हो तो obj.ct () कॉल कर सकते हैं।

UserModel

उपयोगकर्ता मॉडल को ओवरराइड करने की क्षमता संस्करण 1.5 में दिखाई दी।

लेकिन संस्करण 3 के लिए, उन्होंने मानक UserCreationForm / UserChangeForm में मॉडल = उपयोगकर्ता को ठीक नहीं किया।
इसे हल किया गया है:

 from django.contrib.auth.forms import UserCreationForm from django.contrib.auth import get_user_model class MyUserCreationForm(UserCreationForm): class Meta: model= get_user_model() 

अनुवाद प्रणाली

उपयोगकर्ता को दिखाई देने वाले टैग टैग किए गए हैं

 {% trans %} 

या के माध्यम से कोड में

 gettext_lazy 

हालाँकि, व्यवस्थापक पैनल में इन संसाधनों का कोई प्रबंधन नहीं है। आम तौर पर।

बाहरी समाधान हैं, वे सभी किसी न किसी तरह काम करते हैं।

उदाहरण के लिए, रोसेटा व्यवस्थित रूप से पाठ खो देता है, और इंटरफ़ेस छोटी गाड़ी काम कर रहा है। कहीं भी अनुवाद के लिए अधिकारों का सत्यापन नहीं है। काम करने के लिए व्यवस्थित makemessages / compilemessages की आवश्यकता होती है ...

वाइनपैड में, ट्रांस, ब्लॉकट्रांस और गेटटेक्स्ट_लैज टैग को फिर से परिभाषित किया गया और हमने कैश से ग्रंथ प्राप्त करना शुरू किया। यदि कोई कैश नहीं है, तो get_or_create आधार से कैश किए गए अनुरोध ने हमें makemessages से भी बचाया।

बहुभाषावाद का विषय आम तौर पर जटिल है। Django का अंतर्निहित समाधान केवल स्थिर पाठों के लिए काम करता है। लेकिन अभी भी इन मॉडलों का अनुवाद करने की आवश्यकता है। मैंने अपने तरीके से django-TOF परियोजना में गतिशील पाठों के अनुवाद के मुद्दे को हल करने की कोशिश की, जहाँ मैंने मॉडल-अनुवाद और Parler / Hvad की क्षमताओं को संयोजित किया। शायद किसी को झांकने में दिलचस्पी होगी।

अभी के लिए, मैं कथा को रोक दूंगा, क्योंकि Django बग फिक्स लेख आसानी से एक लॉन्ग्रेड में बदल सकता है।

कृपया मुझे बताएं कि आप अपने Django को कैसे सुधार रहे हैं। यदि कोई निरंतरता है, तो मैं उन विचारों को व्यवस्थित करता हूं जो उत्पन्न हुए हैं।

ps कुछ कोड पुरानी संकेतन में लिखे गए हैं, मुझे समझ में आने की उम्मीद है, रिफैक्टरिंग के लिए समय या स्टाफ हमेशा नहीं मिलता है।