उपयोगकर्ता प्रोफाइल: पेशेवरों, विपक्ष, नुकसान

यह कोई रहस्य नहीं है कि Django में उपयोगकर्ता प्रोफाइल के साथ काम करना दुर्भाग्य के अलावा और कुछ नहीं है। हम सभी का सामना करना पड़ा है। इस मॉडल की auth.User का सामना करना पड़ता है। मॉडल, इसमें फ़ील्ड के अपर्याप्त सेट, साथ ही साथ सभी ट्रिक्स का भी सहारा लेना पड़ता था।

सभी को विकृत होना पड़ा: न केवल dzhanga के उपयोगकर्ताओं के लिए, बल्कि इसके मूल डेवलपर्स के लिए भी। उदाहरण के लिए, याद रखें कि Django 1.2 में अचानक username क्षेत्र में कुत्ते के पात्रों (@) और username का उपयोग करना कैसे संभव हो गया? जानते हो क्यों? ताकि आप लॉगिन के रूप में ई-मेल पते का उपयोग कर सकें ।

हम, साधारण उपयोगकर्ता, भी एक कठिन समय था। एक उपयोगकर्ता के प्रोफाइल को बदलने के लिए उसके लिए कुछ दिलचस्प फ़ील्ड जोड़कर - एक सामान्य सी बात, सही? - अलग-अलग तरीकों से कार्य करना पड़ा।

• उदाहरण के लिए, विरासत लें । यह अपने मॉडल बनाने के लिए आवश्यक था auth.User से विरासत में मिला हो।
  
  

   # models.py from django.db import models from django.contrib.auth.models import User class MyUser(User): birthday = models.DateField() 

  
  ... और request.user लिए वर्ग को बदलने के लिए एक मिडलवेयर लिखें। या मिडिलवेयर नहीं, बल्कि AUTHENTICATION_BACKEND । इससे कोई फर्क नहीं पड़ता :)
  
  योजना का लाभ यह था कि हमारा "क्लाइंट" कोड (यानी प्रोजेक्ट कोड) जटिल नहीं था, हमने अपने उपयोगकर्ता के साथ एक नियमित रूप से dzhangovskiy के साथ काम किया।
  
  इस तरह की योजना का मुख्य ऋण यह है कि जब मॉडल को विरासत में लिया जाता है, तो डेटाबेस में एक तालिका नहीं भरी जाती है, लेकिन दो: मूल django_auth django_auth और हमारे ourproj_user , जिसमें django_auth पर एक विदेशी कुंजी django_auth । हां, Django में मॉडल की विरासत कुछ अतिरिक्त विशेषताओं के साथ सिर्फ OneToOneField है। उपयोग करना चाहते हैं - ध्यान रखें।
  
  
• Django के निर्माताओं द्वारा प्रस्तावित कोई कम प्रसिद्ध बैसाखी - तथाकथित प्रोफ़ाइल मॉडल नहीं । हमें एक मॉडल बनाने के लिए कहा गया था जिसके साथ एक auth.User ।
  
  

   # models.py from django.db import models from django.contrib.auth.models import User class Profile(models.Model): user = models.OneToOneField(User) birthday = models.DateField() 

  
  ... और फिर सेटिंग्स में कुछ जोड़ें:
  
  

   AUTH_PROFILE_MODULE = 'accounts.Profile' 

  
  उसके बाद, क्लाइंट कोड में, हम प्रोफाइल के साथ काम कर सकते हैं:
  
  

   profile = request.user.get_profile() profile.birthday = datetime.today() profile.save() 

  
  इसके अलावा, इस तरह की योजना के साथ, मुझे पता नहीं है :) शायद किसी भी नाम के साथ किसी भी क्षेत्र का कोई सेट? Minuses के साथ, सब कुछ अधिक पारदर्शी है:
  
  • समर्थन जटिलता: अब हमारे पास संपादन के लिए एक वस्तु नहीं है, बल्कि दो हैं। हमें यह नहीं भूलना चाहिए कि हम profile लिए जन्म की तारीख बदलते हैं, और, उदाहरण के लिए, user लिए पासवर्ड। कोई आश्चर्य नहीं और भ्रमित हो जाओ।
    
    
  • संसाधनों की अनुचित बर्बादी: get_profile() लिए प्रत्येक कॉल डेटाबेस के लिए एक क्वेरी का कारण बनता है। उन पृष्ठों पर जहां केवल एक उपयोगकर्ता उदाहरण (संपादन, उदाहरण के लिए) है, यह डरावना नहीं है। यदि ऐसी कोई बात है, उदाहरण के लिए, टिप्पणियों में, परिणाम विनाशकारी होगा। बेशक, select_related() , जैसा कि आप समझते हैं, बचत नहीं करेगा, क्योंकि User Profile पर निर्भर नहीं करता है, लेकिन इसके विपरीत।
    
  • और फिर भी आपको अपने हाथों से सब कुछ करना होगा! User मॉडल बनाने का मतलब यह नहीं है कि संबंधित Profile मॉडल स्वचालित रूप से बनाया जाएगा। लेकिन जब एक नए बनाए गए उपयोगकर्ता के लिए get_profile() एक्सेस किया get_profile() , तो एक अपवाद फेंक दिया जाएगा - इसके बारे में कोई संदेह नहीं है। और यद्यपि इस परेशानी का इलाज सरल संकेत के साथ कुछ लाइनों में किया जाता है,
    
    

     # profile.models from django.db import models from django.contrib.auth.models import User class Profile(models.Model): '- ' def create_profile(sender, **kwargs): if kwargs['created']: Profile.objects.create(user=kwargs['instance']) models.signals.post_save.connect(create_profile, sender=User) 

    
    फिर भी कष्टप्रद इसके "मैनुअल" समाधान की आवश्यकता है।
• मैनिपैचिंग , यानी बिना रीराइटिंग कोड के प्रोग्राम के व्यवहार को बदलना। परियोजना में कुछ जगह पर आवेदन को शुरू करने के बाद (मूल नियम में, विशेष रूप से घाव के आवेदन में settings या models ) उन्होंने कोड लिखा था जो हमारे उपयोगकर्ता को संशोधित करता है:
  
  

   # monkey_patching.models from django.db import models from django.contrib.auth.models import User User.add_to_class('birthday', models.DateField() ) 

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

बंदरों का बोलना ...

दुनिया को दिग्गज सोर्ल.थुम्ननेल को देने वालों ने एक बार फिर से उत्कृष्ट प्रदर्शन किया और खाते में एक और हत्यारी चीज बना दी। मिलिए: django- primate, mankipatching के तरीकों (प्राइमेट्स और बंदरों का उपयोग करके, क्या आप सहसंबंध महसूस कर सकते हैं?) अपने खुद के मॉडल को auth.User में auth.User बहुत आसान बनाता है। वह है, रूसी में, वांछित क्षेत्रों की एक प्रोफ़ाइल की रचना करना।

शुरुआत करना काफी आसान है। सबसे पहले आपको django-primate लगाने की आवश्यकता है। यह PyPI के साथ संभव है:

 pip install django-primate 

... और आप उनके भंडार से नवीनतम संस्करण भी प्राप्त कर सकते हैं:

 pip install -e git+https://github.com/aino/django-primate.git#egg=django-primate 

आपको स्टार्टअप पर पैच कॉल करना होगा। निर्माता इसे manage.py सलाह देते हैं

 #!/usr/bin/env python from django.core.management import setup_environ, ManagementUtility import imp try: imp.find_module('settings') # Assumed to be in the same directory. except ImportError: import sys sys.stderr.write( "Error: Can't find the file 'settings.py' in the directory " "containing %r. It appears you've customized things.\nYou'll have to " "run django-admin.py, passing it your settings module.\n" % __file__ ) sys.exit(1) import settings if __name__ == "__main__": setup_environ(settings) import primate primate.patch() ManagementUtility().execute() 

अब वह सब कुछ उस मॉडल settings श्रेणी में निर्दिष्ट करना है जिसे हम उपयोग करना चाहते हैं

 AUTH_USER_MODEL = 'users.models.User' 

... और आप मॉडल के साथ आना शुरू कर सकते हैं:

 # users.models from django.db import models from primate.models import UserBase, UserMeta class User(UserBase): __metaclass__ = UserMeta birthday = models.DateField() #    ? 

अब, जब कोई प्रोजेक्ट घटक django.contrib.auth.models.User , तो उसे एक users.models.User मॉडल प्राप्त होगा। आक्षेप भी सत्य है। व्यवस्थापक पैनल को स्वचालित रूप से पैच किया जाएगा, इसे जोड़ने के लिए किसी विशेष कदम की आवश्यकता नहीं है।

डिफ़ॉल्ट रूप से, django- auth.User उपयोगकर्ता मॉडल में auth.User से निम्नलिखित अंतर हैं:

• फ़ील्ड first_name और last_name , लेकिन name जोड़ा name है;
• अधिकतम username फ़ील्ड की लंबाई 50 अक्षर है ( auth.User यह 30 था)
• email फ़ील्ड में एक अद्वितीय सूचकांक जोड़ा गया है
• get_profile मेथड self वापस आता है, इसलिए आप user.get_profile() का उपयोग करके कोड के बारे में चिंता नहीं कर सकते

अन्यथा, प्राइमेट यूजर मॉडल बत्तख की तरह चलता है, बत्तख की तरह तैरता है और बत्तख की तरह चुटकी बजाता है , यह डेज़ान्गोव्स्की स्रोत की तरह बहुत व्यवहार करता है।

बेशक, आप फ़ील्ड्स के किसी भी सेट का उपयोग कर सकते हैं, लेकिन इस मामले में एक जोखिम है कि तीसरे पक्ष के अनुप्रयोगों के बीच असंगति होगी, इसलिए username , password और email फ़ील्ड का नाम नहीं बदलना बेहतर होगा।

एक और बिंदु: जंग के साथ संगतता के लिए, प्राइमेट मॉडल को डाउनलोड करेगा ताकि इसका app_label users (उदाहरण के रूप में) न हो, लेकिन सामान्य हो। यह दक्षिण उपयोगकर्ताओं के लिए विशेष रूप से सच है जो कुछ समय के लिए समझ नहीं सकते हैं।

 ./manage.py schemamigration users --auto 

कोई माइग्रेशन नहीं बनाता है।

हालांकि, हर कोई README से परिचित हो सकता है, जिसका मैंने बहुत ही स्वतंत्र रूप से अनुवाद किया है। अगर मैंने कुछ याद किया, गलती की या अशुद्धि की, तो टिप्पणियों में लिखें या अपने विचारों को साझा करें।

आपका ध्यान के लिए धन्यवाद :)