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

ठीक है। मुझे पूरा यकीन है कि मेरी समस्या दो कारकों का संयोजन है:

1. DRF को PUT में फ़ील्ड की आवश्यकता नहीं है (भले ही यह मॉडल में आवश्यक हो) क्योंकि इसमें एक डिफ़ॉल्ट (संस्करण = 0) है।
2. DRF PUT फ़ील्ड को वर्तमान ऑब्जेक्ट के साथ मर्ज करता है (डिफ़ॉल्ट इंजेक्शन के बिना)

परिणामस्वरूप, DRF वर्तमान (डेटाबेस) मान का उपयोग करता है और समवर्ती नियंत्रण को तोड़ता है। मुद्दे का दूसरा भाग #3648 (ऊपर भी उद्धृत) में चर्चा से संबंधित है और #1445 में एक (पूर्व 3.x) चर्चा है जो अभी भी प्रासंगिक प्रतीत होती है।

मैं एक ठोस (और तेजी से सामान्य) मामले की उम्मीद कर रहा हूं जहां डिफ़ॉल्ट व्यवहार विकृत है, मॉडलसेरियलाइज़र के "आदर्श" व्यवहार के बारे में चर्चा को फिर से खोलने के लिए पर्याप्त होगा। जाहिर है, मैं डीआरएफ पर केवल एक इंच गहरा हूं, लेकिन मेरा अंतर्ज्ञान यह है कि निम्नलिखित व्यवहार एक आवश्यक क्षेत्र और एक पुट के लिए उपयुक्त है:

• गैर-आंशिक सीरिएलाइज़र का उपयोग करते समय, हमें या तो मान प्राप्त करना चाहिए, डिफ़ॉल्ट का उपयोग करना चाहिए, या (यदि कोई डिफ़ॉल्ट उपलब्ध नहीं है) एक सत्यापन त्रुटि बढ़ाएं। मॉडल-व्यापी सत्यापन केवल इनपुट/चूक पर लागू होना चाहिए।
• आंशिक सीरिएलाइज़र का उपयोग करते समय, हमें या तो मूल्य प्राप्त करना चाहिए या वर्तमान मूल्यों पर फ़ॉलबैक प्राप्त करना चाहिए। मॉडल-व्यापी सत्यापन उस संयुक्त डेटा पर लागू होना चाहिए।
• मेरा मानना ​​​​है कि वर्तमान "गैर-आंशिक" धारावाहिक वास्तव में अर्ध-आंशिक है:
  
  
  
  • यह उन क्षेत्रों के लिए गैर-आंशिक है जो आवश्यक हैं और जिनमें कोई डिफ़ॉल्ट नहीं है
  
  
  • यह आवश्यक फ़ील्ड के लिए आंशिक है और डिफ़ॉल्ट है (क्योंकि डिफ़ॉल्ट का उपयोग नहीं किया जाता है)
  
  
  • यह उन क्षेत्रों के लिए आंशिक है जिनकी आवश्यकता नहीं है
  
  

हम ऊपर बुलेट (1) को नहीं बदल सकते हैं या डिफ़ॉल्ट बेकार हो जाते हैं (हमें इनपुट की आवश्यकता होती है, भले ही हम डिफ़ॉल्ट जानते हों)। इसका मतलब है कि हमें ऊपर #2 बदलकर समस्या को ठीक करना होगा। मैं #2683 में आपके तर्क से सहमत हूं कि:

मॉडल डिफ़ॉल्ट मॉडल डिफ़ॉल्ट हैं। सीरिएलाइज़र को मूल्य को छोड़ देना चाहिए और इसे संभालने के लिए Model.object.create() की जिम्मेदारी स्थगित करनी चाहिए।

चिंताओं के उस अलगाव के अनुरूप होने के लिए, अद्यतन को एक नया उदाहरण बनाना चाहिए (मॉडल में सभी डिफ़ॉल्ट को सौंपना) और सबमिट किए गए मानों को उस नए उदाहरण पर लागू करना चाहिए। यह #3648 में अनुरोधित व्यवहार में परिणत होता है।

माइग्रेशन पथ का वर्णन करने का प्रयास यह उजागर करने में मदद करता है कि वर्तमान व्यवहार कितना अजीब है। अंतिम लक्ष्य है

1. ModelSerializer को ठीक करें,
2. इस अर्ध-आंशिक स्थिति के लिए ध्वज जोड़ें, और
3. उस ध्वज को डिफ़ॉल्ट बनाएं (पिछली संगतता के लिए)

उस झंडे का नाम क्या है? वर्तमान मॉडल सीरिएलाइज़र वास्तव में एक आंशिक धारावाहिक है कि (कुछ हद तक मनमाने ढंग से) उन क्षेत्रों की आवश्यकता होती है जो शर्त को पूरा करते हैं required==True and default==None । हम पश्चगामी संगतता को तोड़े बिना स्पष्ट रूप से partial ध्वज का उपयोग नहीं कर सकते हैं, इसलिए हमें एक नए (उम्मीद के मुताबिक अस्थायी) ध्वज की आवश्यकता है। मेरे पास quasi_partial बचा है, लेकिन मनमानी आवश्यकता required==True and default==None को व्यक्त करने में मेरी अक्षमता इसलिए मेरे लिए इतना स्पष्ट है कि इस व्यवहार को तत्काल हटा दिया जाना चाहिए।

आप सीरिएलाइज़र के मेटा में extra_kwargs जोड़ सकते हैं, जिससे version एक आवश्यक फ़ील्ड बन जाता है।

class ConcurrentModelSerializer(serializers.ModelSerializer):
    class Meta:
        model = ConcurrentModel
        extra_kwargs = {'version': {'required': True}}

धन्यवाद @anoopmalev। वह मुझे प्रोडक्शन ब्रांच में रखेगा।

"इस पर सोने" के बाद मुझे एहसास हुआ कि एक अतिरिक्त शिकन है। मैंने जो कुछ भी कहा वह धारावाहिक के क्षेत्रों पर लागू होना चाहिए। यदि कोई फ़ील्ड धारावाहिक में शामिल नहीं है, तो उसे संशोधित नहीं किया जाना चाहिए। इस तरह, सभी सेरिलाइज़र गैर-शामिल क्षेत्रों के लिए आंशिक हैं (और होना चाहिए)। यह ऊपर मेरे "एक नया उदाहरण बनाएं" से थोड़ा अधिक जटिल है।

मेरा मानना ​​है कि आगे बढ़ने के लिए इस मुद्दे को और अधिक सीमित प्रस्ताव तक सीमित करने की आवश्यकता है।
इसकी वर्तमान स्थिति में कार्रवाई करने योग्य होने के लिए व्यापक लगता है।
अभी के लिए मैं इसे बंद कर रहा हूं - अगर कोई इसे वांछित व्यवहार के संक्षिप्त, कार्रवाई योग्य बयान में कम कर सकता है तो हम पुनर्विचार कर सकते हैं। तब तक मुझे लगता है कि यह केवल व्यापक है।

गैर-आंशिक धारावाहिक के लिए यहां एक संक्षिप्त प्रस्ताव दिया गया है:

1. किसी भी फ़ील्ड के लिए जो सीरिएलाइज़र (निहित या स्पष्ट रूप से) में सूचीबद्ध नहीं है या केवल-पढ़ने के लिए चिह्नित है, मौजूदा मान को सुरक्षित रखें
2. अन्य सभी क्षेत्रों के लिए, उपलब्ध पहले विकल्प का उपयोग करें:
   
   
   
   1. सबमिट किए गए मान के साथ पॉप्युलेट करें
   
   
   2. blank और/या null द्वारा निहित मान सहित, डिफ़ॉल्ट के साथ पॉप्युलेट करें
   
   
   3. एक अपवाद उठाएं
   
   

स्पष्टता के लिए, इस प्रक्रिया के अंतिम उत्पाद पर सत्यापन चलाया जाता है।

यानी आप अपडेट के लिए किसी भी सीरिएलाइज़र फ़ील्ड पर required=True सेट करना चाहते हैं जिसमें मॉडल डिफ़ॉल्ट नहीं है?

क्या मुझे यह सही लगा?

हाँ (और अधिक)। इस तरह मैं partial (सभी फ़ील्ड वैकल्पिक) बनाम non-partial (सभी फ़ील्ड आवश्यक) भेद को समझता हूं। केवल एक non-partial सीरिएलाइज़र को किसी फ़ील्ड की आवश्यकता नहीं होती है, एक डिफ़ॉल्ट (संकीर्ण या व्यापक रूप से परिभाषित) की उपस्थिति होती है _क्योंकि यदि कोई मान प्रदान नहीं किया जाता है तो सीरिएलाइज़र उस डिफ़ॉल्ट का उपयोग कर सकता है।_

इटैलिकाइज़्ड सेक्शन वह है जो वर्तमान में डीआरएफ नहीं कर रहा है और मेरे प्रस्ताव में अधिक महत्वपूर्ण बदलाव है। वर्तमान कार्यान्वयन सिर्फ क्षेत्र को छोड़ देता है।

मेरे पास एक दूसरा प्रस्ताव मिला हुआ था, लेकिन यह वास्तव में एक अलग सवाल है कि आप "डिफ़ॉल्ट" के विचार के साथ कितना उदार होना चाहते हैं। वर्तमान व्यवहार "सख्त" है जिसमें केवल default को इस तरह माना जाता है। यदि आप _वास्तव में आवश्यक डेटा की मात्रा को कम करना चाहते हैं, तो आप blank=True फ़ील्ड को वैकल्पिक भी बना सकते हैं... यह मानते हुए कि एक अनुपस्थित मान एक रिक्त मान है।

@claytondaley मैं इस तरह से 2x से DRF के साथ OOL का उपयोग कर रहा हूं:

class VersionModelSerializer(serializers.ModelSerializer, BaseSerializer):
    _initial_version = 0

    _version = VersionField()

    def __init__(self, *args, **kwargs):
        super(VersionModelSerializer, self).__init__(*args, **kwargs)

        # version field should not be required if there is no object
        if self.instance is None and '_version' in self.fields and\
                getattr(self, 'parent', None) is None:
            self.fields['_version'].read_only = True
            self.fields['_version'].required = False

        # version field is required while updating instance
        if self.instance is not None and '_version' in self.fields:
            self.fields['_version'].required = True

        if self.instance is not None and hasattr(self.instance, '_version'):
            self._initial_version = self.instance._version

    def validate__version(self, value):
        if self.instance is not None:
            if not value and not isinstance(value, int):
                raise serializers.ValidationError(_(u"This field is required"))

        return value
   # more code & helpers

यह सभी प्रकार के व्यावसायिक तर्क के साथ बहुत अच्छा काम करता है और कभी भी कोई समस्या नहीं होती है।

क्या इसे दुर्घटनावश बंद कर दिया गया था? मैंने विशिष्ट प्रश्न का उत्तर दिया और प्रस्ताव में गलत होने का कोई कारण नहीं सुना।

@claytondaley OOL को DRF का हिस्सा क्यों होना चाहिए? मेरा कोड जांचें - यह सिर्फ एक बड़े ऐप (1400 परीक्षण) में काम करता है। VersionField सिर्फ एक IntegerField है।

आपने OOL को सीरिएलाइज़र में हार्ड-कोड किया है। ऐसा करने के लिए यह गलत जगह है क्योंकि आपके पास दौड़ की स्थिति है। समानांतर अद्यतन (उसी पूर्व संस्करण के साथ) सभी धारावाहिक पर पारित होंगे ... लेकिन केवल एक ही बचाने की कार्रवाई पर जीत जाएगा।

मैं django-concurrency का उपयोग कर रहा हूं जो ओओएल तर्क को सेव एक्शन (जहां यह संबंधित है) में डालता है। मूल रूप से UPDATE... WHERE version = submitted_version । यह परमाणु है इसलिए कोई दौड़ की स्थिति नहीं है। हालांकि, यह क्रमबद्धता तर्क में एक दोष को उजागर करता है ::

• यदि मॉडल में किसी फ़ील्ड पर डिफ़ॉल्ट सेट किया गया है, तो DRF required=False सेट करता है। (वैध) विचार यह है कि यदि कोई मान सबमिट नहीं किया जाता है तो डीआरएफ उस डिफ़ॉल्ट का उपयोग कर सकता है।
• यदि वह फ़ील्ड अनुपलब्ध है, तथापि, DRF डिफ़ॉल्ट का उपयोग नहीं करता है। इसके बजाय यह प्रस्तुत डेटा को वस्तु के वर्तमान संस्करण के साथ मिला देता है।

जब हमें फ़ील्ड की आवश्यकता नहीं होती है, तो हम ऐसा इसलिए करते हैं क्योंकि हमारे पास उपयोग करने के लिए एक डिफ़ॉल्ट है। DRF उस अनुबंध को पूरा नहीं करता है क्योंकि यह डिफ़ॉल्ट का उपयोग नहीं करता है... यह मौजूदा मान का उपयोग करता है।

अंतर्निहित मुद्दे पर पहले चर्चा की गई थी, लेकिन उनके पास एक अच्छा, ठोस मामला नहीं था। OOL वह आदर्श मामला है। संस्करण फ़ील्ड का मौजूदा मान हमेशा OOL से गुजरता है ताकि आप संस्करण को छोड़ कर पूरे OOL सिस्टम को बायपास कर सकें। यह (जाहिर है) ओओएल सिस्टम का वांछित व्यवहार नहीं है।

@claytondaley

आपने OOL को सीरिएलाइज़र में हार्ड-कोड किया है।

क्या मैंने? क्या आपको क्षेत्र की आवश्यकता के अलावा मेरे धारावाहिक में कोई ओओएल तर्क मिला है?

ऐसा करने के लिए यह गलत जगह है क्योंकि आपके पास दौड़ की स्थिति है।

श्रीमान, मैं अभी नहीं देख सकता कि यहाँ दौड़ की स्थिति कहाँ है।

मैं django-concurrency का उपयोग कर रहा हूं जो ओओएल तर्क को सेव एक्शन (जहां यह संबंधित है) में रखता है।

मैं django-concurrency का भी उपयोग कर रहा हूं :) लेकिन यह मॉडल स्तर है, धारावाहिक नहीं। धारावाहिक स्तर पर आपको बस यह करना होगा:

• सुनिश्चित करें कि _version फ़ील्ड हमेशा आवश्यक है (जब यह होना चाहिए)
• सुनिश्चित करें कि आपका धारावाहिक जानता है कि ओओएल त्रुटियों को कैसे संभालना है (इस भाग को मैंने छोड़ दिया है)
• सुनिश्चित करें कि आपका एपीआईव्यू जानता है कि ओओएल त्रुटियों को कैसे संभालना है और संभावित भिन्न संदर्भ के साथ HTTP 409 को बढ़ाता है

असल में, मैं किसी ऐसे मुद्दे के कारण django-concurrency का उपयोग नहीं कर रहा हूं जिसे ऑटोर ने "ठीक नहीं किया" के रूप में चिह्नित किया है: यह ओओएल को छोड़ देता है जब obj.save(update_fields=['one', 'two', 'tree']) का उपयोग किया जाता है जिसे मुझे खराब अभ्यास मिला, इसलिए मैंने पैकेज को फोर्क किया।

मैंने पहले उल्लेख किए गए धारावाहिक की लापता save विधि यहां दी गई है। जो आपके सभी मुद्दों को हल करना चाहिए:

    def save(self, **kwargs):
        try:
            self.instance = super(VersionModelSerializer, self).save(**kwargs)
            return self.instance
        except VersionException:
            # Use select_for_update so we have some level of guarantee
            # that object won't be modified at least here at the same time
            # (but it may be modified somewhere else, where select_for_update
            # is not used!)
            with transaction.atomic():
                db_instance = self.instance.__class__.objects.\
                    select_for_update().get(pk=self.instance.pk)
                diff = self._get_serializer_diff(db_instance)

                # re-raise exception, so api client will receive friendly
                # printed diff with writable fields of current serializer
                if diff:
                    raise VersionException(diff)

                # otherwise re-try saving using db_instance
                self.instance = db_instance
                if self.is_valid():
                    return super(VersionModelSerializer, self).save(**kwargs)
                else:
                    # there are errors that could not be displayed to a user
                    # so api client should refresh & retry by itself
                    raise VersionException

        # instance.save() was interrupted by application error
        except ApplicationException as logic_exc:
            if self._initial_version != self.instance._version:
                raise VersionException

            raise logic_exc

माफ़ करना। आप क्या कर रहे थे यह जानने के लिए मैंने आपका कोड नहीं पढ़ा। मैंने एक धारावाहिक देखा। आप स्पष्ट रूप से सीरिएलाइज़र को हैक करके इस मुद्दे के आसपास काम कर सकते हैं लेकिन आपको ऐसा नहीं करना चाहिए .... क्योंकि डीआरएफ तर्क में दोष स्वयं ही है। मैं बिंदु बनाने के लिए सिर्फ ओओएल का उपयोग कर रहा हूं।

और आपको उस कोड को django-concurrency के नवीनतम संस्करण ( IGNORE_DEFAULT=False का उपयोग करके) के विरुद्ध प्रयास करना चाहिए। django-concurrency भी डिफ़ॉल्ट मानों को अनदेखा कर रहा था, लेकिन मैंने एक पैच सबमिट किया। एक अजीब कोने का मामला था जिसे सामान्य मामलों के लिए काम करने के लिए मुझे शिकार करना पड़ा।

मुझे लगता है कि इसे डिफ़ॉल्ट कार्यक्षमता का विस्तार कहा जाता है, वास्तव में हैकिंग नहीं। मुझे लगता है कि इस तरह के फीचर सपोर्ट के लिए सबसे अच्छी जगह django-concurrency पैकेज है।

मैंने पूरे मुद्दे की चर्चा को फिर से पढ़ा है और आपके प्रस्ताव को बहुत व्यापक पाया है और यह कई जगहों पर विफल हो जाएगा (विभिन्न स्थितियों के तहत विभिन्न स्रोतों से डिफ़ॉल्ट मानों का जादुई रूप से उपयोग करने के कारण)। DRF 3.x 2.x की तुलना में बहुत आसान और अनुमानित हो गया है, इसे ऐसे ही रहने दें :)

आप इसे मॉडल लेयर में ठीक नहीं कर सकते क्योंकि यह सीरिएलाइज़र (मॉडल में आने से पहले) पर टूट गया है। OOL को एक तरफ सेट करें... यदि default सेट है तो हमें फ़ील्ड की आवश्यकता क्यों नहीं है?

एक गैर आंशिक धारावाहिक "सभी क्षेत्रों (मौलिक रूप से)" की आवश्यकता होती है और फिर भी हम इसे एक से करते हैं। क्या यह एक बग है? या हमारे पास कोई तार्किक कारण है?

जैसा कि आप मेरे कोड उदाहरण में देख सकते हैं - सभी संभावित मामलों में _version फ़ील्ड हमेशा सही ढंग से आवश्यक है।

बीटीडब्ल्यू, यह पता चला है कि मैंने https://github.com/gavinwahl/django-optimistic-lock से मॉडल lvl कोड उधार लिया है और django-concurrency से नहीं जो लगभग बिना किसी कारण के जटिल है।

... इसलिए बग "गैर-आंशिक धारावाहिकों ने कुछ फ़ील्ड को गलत तरीके से सेट नहीं किया है"। यही विकल्प है। क्योंकि वह (अंतर्निहित) प्रतिबद्धता है जो एक गैर-आंशिक धारावाहिक बनाता है।

मैं इसे उद्धृत कर सकता हूं:

डिफ़ॉल्ट रूप से, धारावाहिकों को सभी आवश्यक क्षेत्रों के लिए मान पारित किया जाना चाहिए या वे सत्यापन त्रुटियों को बढ़ाएंगे।

यह आवश्यक के बारे में कुछ नहीं कहता है (सिवाय जब कोई डिफ़ॉल्ट प्रदान किया जाता है)।

(और मुझे लगता है कि मैं दो अलग-अलग स्तरों के बारे में बात कर रहा हूं, लेकिन मॉडलसेरियलाइज़र को फ़ील्ड की आवश्यकता नहीं होनी चाहिए यदि वह उस निर्णय की ज़िम्मेदारी नहीं ले रहा है)

मुझे लगता है कि मैंने आपकी बात खो दी है ..

(और मुझे लगता है कि मैं दो अलग-अलग स्तरों के बारे में बात कर रहा हूं, लेकिन मॉडलसेरियलाइज़र को फ़ील्ड की आवश्यकता नहीं होनी चाहिए यदि वह उस निर्णय की ज़िम्मेदारी नहीं ले रहा है)

उसमें गलत क्या है?

ठीक है, मुझे एक अलग कोण की कोशिश करने दो।

• मान लें कि मेरे पास एक गैर-आंशिक मॉडल सीरियलाइज़र है (संपादित करें: सभी डिफ़ॉल्ट) जो मेरे मॉडल के सभी क्षेत्रों को कवर करता है।

क्या एक ही डेटा के साथ एक बनाना या अद्यतन करना कभी भी एक अलग वस्तु उत्पन्न करता है (आईडी घटाकर)

क्या आप वास्तव में कुछ सरल मॉडल और धारावाहिक और कुछ पंक्तियों का उपयोग करके अपने विचारों का वर्णन कर सकते हैं जो असफल/अपेक्षित व्यवहार दिखाते हैं?

मैं कल कुछ एक साथ रखूंगा क्योंकि यहां देर हो रही है ... लेकिन मैं जितना गहरा हो जाता हूं, उतना ही अधिक समझ # 3648 एक गैर-आंशिक धारावाहिक के लिए बनाता है। इस बीच, मॉडलसेरियलाइज़र को मॉडल में सभी फ़ील्ड की आवश्यकता क्यों नहीं है? हो सकता है कि आपका तर्क मेरे से अलग हो।

ModelSerializer बंधे हुए मॉडल का निरीक्षण करता है और तय करता है कि क्या इसकी आवश्यकता होनी चाहिए, है ना?

मेरा मतलब यंत्रवत् नहीं है कि कैसे । एक गैर-आंशिक सीरिएलाइज़र के लिए मूल धारणा सब कुछ (ऊपर उद्धृत) की आवश्यकता है। यदि get_field_kwargs इस धारणा से विचलित होने वाला है (विशेष रूप से, यहां ), तो इसका एक अच्छा कारण होना चाहिए। वह कारण क्या है?

मेरा पसंदीदा उत्तर वह है जिसे मैं देता रहता हूं, "क्योंकि यह उस डिफ़ॉल्ट का उपयोग कर सकता है यदि कोई मूल्य जमा नहीं किया गया है" (लेकिन तब डीआरएफ को वास्तव में डिफ़ॉल्ट का उपयोग करना पड़ता है)। क्या कोई और जवाब है जो मुझे याद आ रहा है? एक कारण है कि चूक वाले क्षेत्रों की आवश्यकता क्यों नहीं होनी चाहिए?

जाहिर है, मैं "पूर्ण" समाधान पसंद करता हूं। हालाँकि, मैं मानता हूँ कि एक दूसरा उत्तर है। हमें डिफ़ॉल्ट रूप से इन क्षेत्रों की आवश्यकता हो सकती है। यह (वर्तमान में मनमाना) विशेष मामले को समाप्त करता है। यह कोड को सरल/कम करता है। यह आंतरिक रूप से सुसंगत है। यह मेरी चिंता को संबोधित करता है।

मूल रूप से, यह गैर-आंशिक धारावाहिक को वास्तव में गैर-आंशिक बनाता है।

अब मुझे कम से कम पता है कि आपका क्या मतलब है। क्या आपने जाँच की है कि ऐसे मामले में ModelForm व्यवहार क्या है? (यह खुद मोबाइल पर नहीं कर सकते)

Django दस्तावेज़ कहता है कि 'रिक्त' नियंत्रित करता है कि फ़ील्ड आवश्यक है या नहीं। मेरा सुझाव है कि आपको इस मुद्दे के लिए एक अलग टिकट खोलना चाहिए क्योंकि इसमें बहुत सारी असंबंधित टिप्पणियां हैं। मेरी राय में मॉडलरियलाइज़र मॉडलफॉर्म की तरह काम कर सकता है: रिक्त विकल्प नियंत्रण आवश्यक है, 'शून्य' बताता है कि कोई भी स्वीकार्य इनपुट नहीं है और 'डिफ़ॉल्ट' का उस तर्क पर कोई प्रभाव नहीं पड़ता है।

मैं दूसरा टिकट खोलने को तैयार हूं, लेकिन मुझे चिंता है कि रिक्त के लिए समान कोड की आवश्यकता है। django चर्चा समूह से:

यदि हम एक मौजूदा मॉडल फॉर्म और टेम्प्लेट लेते हैं जो काम करता है, तो मॉडल में एक वैकल्पिक वर्ण फ़ील्ड जोड़ें, लेकिन HTML टेम्प्लेट में संबंधित फ़ील्ड जोड़ने में विफल (उदाहरण के लिए मानवीय त्रुटि, एक टेम्प्लेट के बारे में भूल गए, टेम्प्लेट लेखक को बनाने के लिए नहीं बताया) एक परिवर्तन, एक टेम्पलेट में किए जाने के लिए आवश्यक परिवर्तन का एहसास नहीं हुआ), जब वह फॉर्म जमा किया जाता है तो Django यह मान लेगा कि उपयोगकर्ता ने लापता फ़ील्ड के लिए एक खाली स्ट्रिंग मान प्रदान किया है और किसी भी मौजूदा मान को मिटाते हुए उसे मॉडल में सहेजा है। .

सुसंगत होने के लिए, हमारे पास अनुबंध की दूसरी छमाही को पूरा करने का दायित्व होगा, अनुपस्थित मान को रिक्त पर सेट करना। यह थोड़ा कम समस्याग्रस्त है क्योंकि किसी मॉडल के संदर्भ के बिना रिक्त स्थान भरा जा सकता है, लेकिन यह बहुत समान है (और, मुझे लगता है, # 3648 के अनुरूप)।

@tomchristie क्या आप इस पर कुछ संक्षिप्त जानकारी दे सकते हैं: क्यों required राज्य मॉडल फ़ील्ड defaults संपत्ति पर निर्भर करता है?

क्यों आवश्यक राज्य मॉडल फ़ील्ड डिफ़ॉल्ट संपत्ति पर निर्भर करता है?

बस यह: यदि किसी मॉडल फ़ील्ड में डिफ़ॉल्ट है, तो आप इसे इनपुट के रूप में प्रदान करना छोड़ सकते हैं।

दरअसल मैं इस व्यवहार से सहमत हूं। मॉडलफॉर्म कोड के बावजूद वही कर रहा है (जेनरेट किया गया एचटीएमएल डिफ़ॉल्ट प्रदान करेगा)। यदि डीआरएफ अलग तर्क देगा तो 'डिफ़ॉल्ट' कभी लागू नहीं होगा। मैं इस मुद्दे के साथ किया है।

@pySilver वास्तव में, यहां मॉडलफॉर्म व्यवहार है:

# models.py

from django.db import models

class MyModel(models.Model):
    no_default = models.CharField(max_length=100)
    has_default = models.CharField(max_length=100, default="iAmTheDefault")

स्पष्टता के लिए, सामान को अभी भी "आंशिक" नाम दिया गया है क्योंकि _update_ आंशिक है। मैं एक पूर्ण ("पूर्ण") अद्यतन का भी परीक्षण कर रहा था, लेकिन व्यवहार दिखाने के लिए कोड अनावश्यक था:

# in manage.py shell
>>> from django import forms
>>> from django.conf import settings
>>> from form_serializer.models import MyModel
>>>
>>> class MyModelForm(forms.ModelForm):
...     class Meta:
...         model = MyModel
...         fields = ['no_default', 'has_default']
...
>>>
>>> partial = MyModel.objects.create()
>>> partial.id = 2
>>> partial.no_default = "Must replace me"
>>> partial.has_default = "I should be replaced"
>>> partial.save()
>>>
>>>
>>> POST_PARTIAL = {
...     "id": 2,
...     "no_default": "must change me",
... }
>>>
>>>
>>> form_partial = MyModelForm(POST_PARTIAL)
>>> form_partial.is_valid()
False
>>> form_partial._errors
{'has_default': [u'This field is required.']}

ModelForm को इस इनपुट की आवश्यकता है, यह भी सोचा कि इसमें एक डिफ़ॉल्ट है। यह दो आंतरिक रूप से सुसंगत व्यवहारों में से एक है।

क्यों आवश्यक राज्य मॉडल फ़ील्ड डिफ़ॉल्ट संपत्ति पर निर्भर करता है?

बस यह: यदि किसी मॉडल फ़ील्ड में डिफ़ॉल्ट है, तो आप इसे इनपुट के रूप में प्रदान करना छोड़ सकते हैं।

@tomchristie सिद्धांत रूप में सहमत हैं। लेकिन अपेक्षित व्यवहार क्या है?

• बनाने पर, मुझे डिफ़ॉल्ट मिलता है (तुच्छ, हर कोई सहमत है कि यह सही है)
• अद्यतन होने पर, मुझे क्या प्राप्त करना चाहिए?

मुझे ऐसा लगता है कि मुझे अपडेट पर भी डिफ़ॉल्ट मिलना चाहिए। मैं नहीं देखता कि एक गैर-आंशिक धारावाहिक को दो मामलों में अलग-अलग व्यवहार क्यों करना चाहिए। गैर-आंशिक का मतलब है कि मैं "पूर्ण" रिकॉर्ड भेज रहा हूं। इस प्रकार पूरा रिकॉर्ड बदला जाना चाहिए।

मुझे उम्मीद है कि अगर यह अद्यतन पर प्रदान नहीं किया गया है तो मूल्य अपरिवर्तित रहेगा। मैं बिंदु देखता हूं, लेकिन डिफ़ॉल्ट मान के साथ पारदर्शी रूप से ओवरराइट करना मेरे पीओवी से प्रति-सहज होगा।

(अगर कुछ भी मुझे लगता है कि यह वास्तव में सभी अपडेट के लिए सभी क्षेत्रों के लिए आंशिक अर्थशास्त्र होने के लिए बेहतर होगा - पुट अभी भी बेवकूफ होगा, जो महत्वपूर्ण पहलू है, संभवतः वर्तमान व्यवहार को बदलने के लिए अजीब है)

मैं निश्चित रूप से आपको प्राथमिकताएं साझा नहीं करता; मैं चाहता हूं कि मेरे सभी इंटरफेस सख्त हों जब तक कि मैं जानबूझकर उन्हें अन्यथा नहीं बनाता। हालांकि, आपका आंशिक बनाम गैर-आंशिक भेद पहले से ही (सिद्धांत रूप में) प्रदान करता है जो हम दोनों चाहते हैं।

मेरा मानना ​​​​है कि आंशिक व्यवहार ठीक वैसा ही है जैसा आप चाहते हैं:

• अद्यतन 100% आंशिक हैं
• default और blank (तार्किक अपवाद) के संबंध में CREATEs (मुझे लगता है) आंशिक हैं। अन्य सभी मामलों में मॉडल/डेटाबेस बाधाएं बाध्य होती हैं।

मैं सिर्फ गैर-आंशिक धारावाहिक में निरंतरता प्राप्त करने की कोशिश कर रहा हूं। यदि आप default के लिए विशेष-मामले को समाप्त करते हैं, तो आपके मौजूदा गैर-आंशिक धारावाहिक सख्त धारावाहिक बन जाते हैं जो मैं चाहता हूं। वे ModelForm के साथ समानता तक पहुंचते हैं।

मुझे एहसास है कि यह परियोजना के भीतर एक छोटा सा असंतुलन पैदा करता है, लेकिन यह पहली बार नहीं है जब किसी ने इस तरह बदलाव किया है। वर्तमान व्यवहार में डिफ़ॉल्ट रूप से "विरासत" ध्वज जोड़ें, एक चेतावनी जोड़ें (कि डिफ़ॉल्ट व्यवहार बदल जाएगा), और बाद के प्रमुख रिलीज में डिफ़ॉल्ट को बदलें।

सबसे महत्वपूर्ण बात यह है कि यदि आप चाहते हैं कि आपके धारावाहिक Django के लिए नया वास्तविक हो, तो आप वैसे भी इस बदलाव को समाप्त करने जा रहे हैं। ModelForm से रूपांतरित होने वाले लोगों की संख्या मौजूदा उपयोगकर्ता आधार से बहुत अधिक हो जाएगी और वे कम से कम इस परिवर्तन की अपेक्षा करेंगे।

मेरे दो सेंट सम्मिलित करना:
मैं @claytondaley से सहमत होने के इच्छुक हूं। PUT एक बेकार संसाधन प्रतिस्थापन है, PATCH मौजूदा संसाधन का एक अद्यतन है। निम्नलिखित उदाहरण लें:

class Profiles(models.Model):
    username = models.CharField()
    role = models.CharField(default='member', choices=(
        ('member', 'Member'), 
        ('moderator', 'Moderator'),
        ('admin', 'Admin'), 
    ))

नई प्रोफ़ाइल में समझदारी से डिफ़ॉल्ट सदस्य भूमिका होती है। आइए निम्नलिखित अनुरोध लें:

POST /profiles username=moe
PUT /profiles/1 username=curly
PATCH /profiles/1 username=larry&role=admin
PUT /profiles/1 username=curly

जैसा कि यह वर्तमान में खड़ा है, पहले PUT के बाद, प्रोफ़ाइल डेटा में {'username': 'curly', 'role': 'member'} होगा। दूसरे पुट के बाद, आपके पास {'username': 'curly', 'role': 'admin'} होगा। क्या इससे नपुंसकता नहीं टूटती? (मैं पूरी तरह से निश्चित नहीं हूं - वैध रूप से पूछ रहा हूं)

संपादित करें:
मुझे लगता है कि पैच के शब्दार्थ के बारे में हर कोई एक ही पृष्ठ पर है।

दूसरे PUT के बाद, आपके पास {'उपयोगकर्ता नाम': 'घुंघराले', 'भूमिका': 'व्यवस्थापक'} होगा

मुझे, व्यक्तिगत रूप से आश्चर्य होगा यदि भूमिका डिफ़ॉल्ट रूप से वापस आ जाएगी (मैं इस replace वस्तु चर्चा का कारण देखता हूं, मेरे पास अभी तक इसके साथ कोई वास्तविक दुनिया के मुद्दे नहीं हैं)

मुझे इसके साथ अभी तक कोई वास्तविक दुनिया की समस्या नहीं हुई है

यहां वही है, लेकिन अभी तक हमारी परियोजनाएं पैच पर निर्भर हैं :)
उस ने कहा, समेकन को संभालने के लिए ओपी का उपयोग केस w/मॉडल वर्जनिंग मुझे समझ में आता है। मैं उम्मीद करता हूं कि PUT डिफ़ॉल्ट मान का उपयोग करे (यदि मान छोड़ा गया है), समवर्ती अपवाद को बढ़ाते हुए।

मुझे यह स्वीकार करते हुए शुरू करना चाहिए कि एक धारावाहिक को जरूरी नहीं कि RESTful RFC का पालन किया जाए। हालांकि, उन्हें कम से कम _are_ संगत मोड की पेशकश करनी चाहिए - विशेष रूप से ऐसे पैकेज में जो आरईएसटी समर्थन प्रदान कर रहा है।

मेरा मूल तर्क पहले सिद्धांतों से था, लेकिन आरएफसी (धारा 4.3.4) विशेष रूप से कहता है (जोर जोड़ा गया):

POST और PUT विधियों के बीच मूलभूत अंतर को संलग्न प्रतिनिधित्व के लिए अलग-अलग इरादे से उजागर किया गया है। POST अनुरोध में लक्ष्य संसाधन का उद्देश्य संसाधन के अपने शब्दार्थ के अनुसार संलग्न प्रतिनिधित्व को संभालना है, जबकि PUT अनुरोध में संलग्न प्रतिनिधित्व को लक्ष्य संसाधन की स्थिति को बदलने के रूप में परिभाषित किया गया है।
...
एक मूल सर्वर जो किसी दिए गए लक्ष्य संसाधन पर पुट की अनुमति देता है, उसे पुट अनुरोध के लिए 400 (खराब अनुरोध) प्रतिक्रिया भेजनी चाहिए जिसमें सामग्री-श्रेणी शीर्षलेख फ़ील्ड ([आरएफसी7233] की धारा 4.2) शामिल है, क्योंकि पेलोड आंशिक सामग्री होने की संभावना है जिसे गलती से एक पूर्ण प्रतिनिधित्व के रूप में डाल दिया गया है । आंशिक सामग्री अपडेट राज्य के साथ अलग से पहचाने गए संसाधन को लक्षित करके संभव है जो बड़े संसाधन के एक हिस्से को ओवरलैप करता है, या एक अलग विधि का उपयोग करके जिसे आंशिक अपडेट के लिए विशेष रूप से परिभाषित किया गया है (उदाहरण के लिए, [आरएफसी 5789] में परिभाषित पैच विधि)

तो एक पुट कभी भी आंशिक नहीं होना चाहिए (यह भी देखें, यहां )। हालाँकि, PUT पर अनुभाग यह भी स्पष्ट करता है:

PUT विधि अनुरोध करती है कि लक्ष्य संसाधन की स्थिति को अनुरोध संदेश पेलोड में संलग्न प्रतिनिधित्व द्वारा परिभाषित राज्य के साथ बनाया या प्रतिस्थापित किया जाए। किसी दिए गए प्रतिनिधित्व का एक सफल पुट यह सुझाव देगा कि उसी लक्ष्य संसाधन पर बाद में प्राप्त होने के परिणामस्वरूप 200 (ठीक) प्रतिक्रिया में समकक्ष प्रतिनिधित्व भेजा जाएगा।

जीईटी के बारे में बिंदु (जबकि अनिवार्य नहीं है) मेरे "समझौता" समाधान के लिए तर्क देता है। जबकि ब्लैंक/डिफॉल्ट को इंजेक्ट करना सुविधाजनक है, यह इस व्यवहार को प्रदान नहीं करेगा। ताबूत में कील शायद यह है कि यह समाधान भ्रम को कम करता है क्योंकि संदेह पैदा करने के लिए कोई लापता क्षेत्र नहीं होगा।

जाहिर है, पैच आंशिक अपडेट के लिए एक निर्दिष्ट विकल्प है, लेकिन इसे केवल आंशिक पुट के बजाय "निर्देशों का सेट" के रूप में वर्णित किया गया है, इसलिए यह हमेशा मुझे थोड़ा परेशान करता है। POST (4.3.3) पर अनुभाग वास्तव में कहता है:

POST विधि अनुरोध करती है कि लक्ष्य संसाधन संसाधन के अपने विशिष्ट शब्दार्थ के अनुसार अनुरोध में संलग्न प्रतिनिधित्व को संसाधित करता है। उदाहरण के लिए, POST का उपयोग निम्नलिखित कार्यों (दूसरों के बीच) के लिए किया जाता है:

• डेटा-हैंडलिंग प्रक्रिया के लिए डेटा का एक ब्लॉक प्रदान करना, जैसे कि HTML फॉर्म में दर्ज की गई फ़ील्ड;

...

• किसी संसाधन के मौजूदा प्रतिनिधित्व में डेटा जोड़ना।

मुझे लगता है कि आंशिक अपडेट के लिए POST का उपयोग करने के लिए एक तर्क है:

• अवधारणात्मक रूप से, डेटा में संशोधन करना संलग्न करने से भिन्न नहीं है
• POST को अपने स्वयं के नियमों का उपयोग करने की अनुमति है ताकि वे नियम आंशिक अपडेट हो सकें
• इस ऑपरेशन को आसानी से एक आईडी की उपस्थिति से क्रिएट से अलग किया जा सकता है

यहां तक ​​कि अगर डीआरएफ पूर्ण अनुपालन की आकांक्षा नहीं रखता है, तो हमें एक सीरिएलाइज़र की आवश्यकता होती है जो स्पेक पुट ऑपरेशन (यानी पूरे ऑब्जेक्ट को बदलना) के साथ संगत हो। सबसे सरल (और स्पष्ट रूप से कम से कम भ्रमित करने वाला) उत्तर सभी क्षेत्रों की आवश्यकता है। यह भी सुझाव देता है कि पुट डिफ़ॉल्ट रूप से गैर-आंशिक होना चाहिए और आंशिक अपडेट में एक अलग कीवर्ड (पैच या यहां तक ​​कि पोस्ट) का उपयोग करना चाहिए।

मुझे लगता है कि मैंने अपने ऐप को drf3.4.x पर माइग्रेट करते समय अपना पहला पुट मुद्दा मारा है :)

<strong i="6">@cached_property</strong>
    def _writable_fields(self):
        return [
            field for field in self.fields.values()
            if (not field.read_only) or (field.default is not empty)
        ]

इससे मेरे .validated_data में डेटा होता है जो मैंने PUT अनुरोध में प्रदान नहीं किया था और मैंने मैन्युअल रूप से सीरियलाइज़र के भीतर प्रदान नहीं किया था। सीरियलाइज़र स्तर पर मान default= से पुनर्प्राप्त किए गए थे। तो मूल रूप से विशेष फ़ील्ड को अपडेट करने का इरादा रखते हुए, मैं उन कुछ फ़ील्ड को नीले रंग से डिफ़ॉल्ट मानों के साथ ओवरराइट करता हूं।

मेरे लिए खुश, मैं कस्टम मॉडलसेरियलाइज़र का उपयोग कर रहा हूं, इसलिए मैं इस मुद्दे को आसानी से ठीक कर सकता हूं।

@pySilver मैं नवीनतम टिप्पणी की सामग्री को नहीं समझता।

@rpkilby "आइए निम्नलिखित अनुरोध करें ... क्या यह बेवकूफी नहीं तोड़ता है"

नहीं, प्रत्येक पुट अनुरोध इस मायने में बेकार है कि इसे एक ही स्थिति में कई बार दोहराया जा सकता है। इसका मतलब यह नहीं है कि अगर इस बीच राज्य के किसी अन्य हिस्से को संशोधित किया गया है तो इसे किसी तरह रीसेट कर दिया जाएगा।

PUT व्यवहार के लिए यहां कुछ अलग विकल्प दिए गए हैं।

• फ़ील्ड आवश्यक हैं जब तक कि required=False या उनके पास default न हो। (मौजूदा)
• सभी फ़ील्ड आवश्यक हैं। (सख्त, पूर्ण अद्यतन _but_ के अधिक बारीकी से संरेखित शब्दार्थ अजीब है क्योंकि यह वास्तव में POST के लिए प्रारंभिक निर्माण शब्दार्थ से अधिक कठोर है)
• किसी फ़ील्ड की आवश्यकता नहीं है (यानी बस मिरर पैच व्यवहार)

स्पष्ट करें कि कोई _absolute_ सही उत्तर नहीं है, लेकिन मेरा मानना ​​​​है कि हमें सबसे व्यावहारिक व्यवहार मिला है जैसा कि वर्तमान में है।

मेरा मानना ​​​​है कि कुछ उपयोग के मामलों में यह समस्याग्रस्त हो सकता है यदि कोई ऐसा क्षेत्र है जिसे POST अनुरोधों के लिए प्रदान करने की आवश्यकता नहीं है, लेकिन बाद में PUT अनुरोधों के लिए करता है। इसके अलावा, PUT-as-create अपने आप में एक वैध ऑपरेशन है, इसलिए फिर से, यह अजीब होगा यदि उसके पास POST के लिए अलग "आवश्यकता" शब्दार्थ है।

अगर कोई इसे आगे ले जाना चाहता है तो मैं _strongly_ तीसरे पक्ष के पैकेज के रूप में शुरू करने का सुझाव दूंगा, जो अलग-अलग आधार धारावाहिक वर्गों को लागू करता है। इसके बाद हम इसे धारावाहिक दस्तावेज से लिंक कर सकते हैं। यदि मामला अच्छी तरह से बना है, तो हम भविष्य में किसी बिंदु पर डिफ़ॉल्ट व्यवहार को अपनाने पर विचार कर सकते हैं।

@tomchristie मैं क्या कहना चाहता हूं:

मेरे पास केवल language फ़ील्ड और एक मॉडल के साथ एक धारावाहिक है:

class Book(models.Model):
      title = models.CharField(max_length=100)
      language = models.ChoiceField(default='en', choices=(('pl', 'Polish'), ('en', 'English'))

class BookUpdateSerialzier(serializers.ModelSerializer):
      # language is readonly, I dont want to let users update that field using this serializer
      language = serializers.ChoiceField(default='en', choices=(('pl', 'Polish'), ('en', 'English'), read_only=True)
      class Meta:
          model = MyModel
          fields = ('title', 'language', )

book = Book(title="To be or 42", language="pl")
book.save()

s = BookUpdateSerialzier(book, data={'title': 'Foobar'}, partial=True)
s.is_valid()
assert 'language' in s.validated_data # !!! 
assert 'pl' == s.validated_data # AssertionError... here :(

• मैंने अनुरोध में language पास नहीं किया और मुझे इसे मान्य डेटा में देखने की उम्मीद नहीं है। update पास होने के कारण यह मेरे उदाहरण को डिफ़ॉल्ट के साथ अधिलेखित कर देगा, इस तथ्य के बावजूद कि ऑब्जेक्ट में पहले से ही कुछ गैर-डिफ़ॉल्ट मान असाइन किया गया है।
• यह कम समस्याग्रस्त होगा यदि उस स्थिति में validated_data['language'] book.language होगा।

@pySilver - हाँ, इसे आज ही https://github.com/tomchristie/django-rest-framework/pull/4346 में हल कर लिया गया है।

जैसा कि ऐसा होता है, आपको अपने उदाहरण में सीरिएलाइज़र फ़ील्ड पर default= की आवश्यकता नहीं है, क्योंकि आपके पास ModelField पर डिफ़ॉल्ट है।

@tomchristie क्या आप कम से कम सहमत हैं कि वर्तमान PUT व्यवहार RFC युक्ति नहीं है? और यह कि मेरे दोनों सुझाव (सभी की आवश्यकता है या चूक इंजेक्ट करें) ऐसा करेंगे?

@tomchristie अच्छी खबर है!

जैसा कि ऐसा होता है, आपको अपने उदाहरण में सीरिएलाइज़र फ़ील्ड पर डिफ़ॉल्ट = की आवश्यकता नहीं है, क्योंकि आपके पास मॉडलफिल्ड पर डिफ़ॉल्ट है।

हाँ, मैं इसे डेमो के लिए सुपर स्पष्ट करना चाहता था।

यह अंत में डूब रहा है कि @tomchristie अलगाव में धारावाहिक व्यवहार के लिए/के खिलाफ बहस नहीं कर रहा है। मेरा मानना ​​​​है कि उनकी आपत्तियां (निहित रूप से) इस आवश्यकता से हैं कि एक एकल धारावाहिक सभी आरईएसटी मोड का समर्थन करता है। यह उनकी शिकायतों में खुद को प्रदर्शित करता है कि एक सख्त धारावाहिक एक POST को कैसे प्रभावित करेगा। चूंकि आरईएसटी मोड असंगत हैं, वर्तमान समाधान एक धारावाहिक है जो किसी एकल मोड के लिए विशिष्ट नहीं है।

अगर यह आपत्ति की असली जड़ है, तो आइए इसे आगे बढ़ाते हैं। एक एकल धारावाहिक सभी आरईएसटी मोड के लिए विशिष्ट व्यवहार कैसे प्रदान कर सकता है? मेरा ऑफ-द-कफ उत्तर यह है कि आंशिक बनाम गैर-आंशिक गलत स्तर पर लागू किया गया है:

• हमारे पास आंशिक और गैर-आंशिक धारावाहिक हैं। इस दृष्टिकोण का मतलब है कि हमें सभी मोड के लिए विशिष्ट व्यवहार का समर्थन करने के लिए कई धारावाहिकों की आवश्यकता है।
• हमें वास्तव में आंशिक बनाम गैर-आंशिक सत्यापन (या इस नस में कुछ) की आवश्यकता है। विभिन्न आरईएसटी मोड को धारावाहिक से विभिन्न सत्यापन मोड का अनुरोध करने की आवश्यकता होती है।

चिंताओं को अलग करने के लिए, एक धारावाहिक को आरईएसटी मोड नहीं पता होना चाहिए, इसलिए इसे तीसरे पक्ष के धारावाहिक के रूप में लागू नहीं किया जा सकता है (न ही, मुझे संदेह है, क्या धारावाहिक के पास भी मोड तक पहुंच है)। इसके बजाय, डीआरएफ को सीरिएलाइज़र को अतिरिक्त जानकारी देनी चाहिए (लगभग replace=True PUT के लिए)। धारावाहिक यह तय कर सकता है कि इसे कैसे कार्यान्वित किया जाए (सभी फ़ील्ड की आवश्यकता है या डिफ़ॉल्ट इंजेक्ट करें)।

जाहिर है, यह सिर्फ एक मोटा प्रस्ताव है, लेकिन शायद यह गतिरोध को तोड़ देगा।

इसके अलावा, PUT-as-create स्वयं एक वैध ऑपरेशन है, इसलिए फिर से, यह अजीब होगा यदि उसके पास POST के लिए अलग-अलग "आवश्यकता" शब्दार्थ हों।

मैं सहमत हूं कि आप एक पुट के साथ बना सकते हैं, लेकिन मैं असहमत हूं कि शब्दार्थ समान हैं। PUT एक विशिष्ट संसाधन पर काम करता है:

PUT विधि अनुरोध करती है कि लक्ष्य संसाधन की स्थिति को अनुरोध संदेश पेलोड में संलग्न प्रतिनिधित्व द्वारा परिभाषित राज्य के साथ बनाया या प्रतिस्थापित किया जाए।

इसलिए, मेरा मानना ​​​​है कि निर्माण शब्दार्थ वास्तव में भिन्न हैं:

• पदसे /citizen/ एक SSN (सामाजिक सुरक्षा संख्या) उत्पन्न होने की अपेक्षा करता है
• रखनासे /citizen/<SSN> एक विशिष्ट SSN के लिए डेटा अपडेट करता है। यदि उस एसएसएन में कोई डेटा नहीं है, तो इसका परिणाम एक निर्माण में होता है।

चूंकि "आईडी" को पुट के यूआरआई में शामिल किया जाना चाहिए, आप इसे आवश्यकतानुसार मान सकते हैं। इसके विपरीत, POST में "id" वैकल्पिक है।

चूंकि "आईडी" को पुट के यूआरआई में शामिल किया जाना चाहिए, आप इसे आवश्यकतानुसार मान सकते हैं। इसके विपरीत, POST में "id" वैकल्पिक है।

वास्तव में। मैं विशेष रूप से इस तथ्य की बात कर रहा था कि "मेक पुट को सख्ती से _all_ फ़ील्ड की आवश्यकता है" के प्रस्तावित परिवर्तन का अर्थ यह होगा कि पुट-एज़-क्रिएट का POST-as-create wrt के लिए अलग व्यवहार होगा। यदि फ़ील्ड आवश्यक हैं या नहीं।

यह कहकर कि मैं पुट-इज़-सख्त व्यवहार का विकल्प रखने में मूल्य के आसपास आ रहा हूं।

(लागू करें कि इस मामले में _all_ फ़ील्ड की सख्त आवश्यकता है, लागू करें कि _no_ फ़ील्ड PATCH में आवश्यक हैं, और POST के लिए required= ध्वज का उपयोग करें)

एक एकल धारावाहिक सभी आरईएसटी मोड के लिए विशिष्ट व्यवहार कैसे प्रदान कर सकता है?

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

आप पहले ही बता चुके हैं कि आप create का उपयोग करके PUT या POST का उपयोग कर सकते हैं। उनके पास अलग-अलग शब्दार्थ और अलग-अलग आवश्यकताएं हैं इसलिए create को REST मोड के लिए अज्ञेयवादी होने की आवश्यकता है। मुझे लगता है कि भेद वास्तव में is_valid के हिस्से के रूप में होता है। हम एक विशिष्ट सत्यापन मोड के लिए कहते हैं:

• कोई फ़ील्ड-उपस्थिति सत्यापन नहीं (पैच)
• required झंडे (पोस्ट) के आधार पर सत्यापन
• सख्त क्षेत्र-उपस्थिति सत्यापन (PUT)

कीवर्ड-विशिष्ट तर्क को सीआरयूडी संचालन से बाहर रखकर, हम सीरिएलाइज़र और डीआरएफ के बीच युग्मन को भी कम करते हैं। यदि सत्यापन मोड कॉन्फ़िगर करने योग्य थे, तो वे पूरी तरह से सामान्य-उद्देश्य वाले होंगे (भले ही हम अपने 3 कीवर्ड के लिए केवल 3 विशिष्ट मामलों को लागू करें)।

आप मुझे इस कार्यक्षमता के बारे में बहस करने का अच्छा काम कर रहे हैं। :)

.is_valid() को कॉल करते समय भिन्न "सत्यापन मोड" एक उथल-पुथल है जो उड़ने वाला नहीं है।

हम शायद मौजूदा 'आंशिक = सही' इकाई kwarg के समकक्ष 'पूर्ण = सही' पर विचार कर सकते हैं। यह आसानी से पर्याप्त रूप से फिट होगा कि चीजें वर्तमान में कैसे काम करती हैं और अभी भी "सख्त फ़ील्ड" मामले का समर्थन करेगी।

क्या धारावाहिक इस समस्या को हल करने के लिए सही जगह है? इस आवश्यकता को आरईएसटी कीवर्ड के साथ कसकर जोड़ा गया है, इसलिए शायद इसे लागू करने के लिए यह सही जगह है। इस दृष्टिकोण का समर्थन करने के लिए, धारावाहिक को केवल उन क्षेत्रों की एक सूची को उजागर करने की आवश्यकता होती है जिन्हें वह इनपुट के रूप में स्वीकार करता है,

एक तरफ से अधिक ... क्या Django की चिंताओं के अलगाव (आवंटन) की कहीं अच्छी चर्चा है? मुझे अपने आप को Django के अनुकूल उत्तरों तक सीमित करने में परेशानी हो रही है क्योंकि मुझे "क्रमबद्धता का सत्यापन हिस्सा क्यों है" जैसे प्रश्नों का उत्तर नहीं पता है। 1.9 के लिए क्रमांकन दस्तावेज़ सत्यापन का भी उल्लेख नहीं करते हैं। और, सख्ती से पहले सिद्धांत से, ऐसा लगता है:

1. मॉडल आंतरिक स्थिरता को मान्य करने के लिए जिम्मेदार होना चाहिए और
2. "व्यू" (इस मामले में, आरईएसटी मोड प्रोसेसर) उस दृश्य से संबंधित व्यावसायिक नियमों (आरएफसी की तरह) को लागू करने के लिए ज़िम्मेदार होना चाहिए।

यदि सत्यापन की जिम्मेदारी समाप्त हो जाती है, तो धारावाहिक 100% आंशिक (डिफ़ॉल्ट रूप से) हो सकते हैं और I/O नियमों जैसे "केवल पढ़ने के लिए" के लिए विशिष्ट हो सकते हैं। इस तरह से बनाया गया एक ModelSerializer विभिन्न प्रकार के विचारों का समर्थन करेगा।

क्या धारावाहिक इस समस्या को हल करने के लिए सही जगह है?

हां।

1.9 के लिए क्रमांकन दस्तावेज़ सत्यापन का भी उल्लेख नहीं करते हैं।

Django का अंतर्निर्मित क्रमांकन वेब APIS के लिए उपयोगी नहीं है, यह वास्तव में डंपिंग और लोडिंग फिक्स्चर तक सीमित है।

आप Django और DRF दोनों की वास्तु धारणाओं को मुझसे बेहतर जानते हैं इसलिए मुझे आपको यह बताना चाहिए कि कैसे। निश्चित रूप से एक init kwarg के पास इसका सही अनुभव है ... "ऑन-डिमांड" धारावाहिक को पुन: कॉन्फ़िगर करना। एकमात्र सीमा यह है कि उन्हें "मक्खी पर" पुन: कॉन्फ़िगर नहीं किया जा सकता है, लेकिन मुझे लगता है कि उदाहरण एकल उपयोग हैं इसलिए यह एक महत्वपूर्ण मुद्दा नहीं है।

मैं अभी के लिए इसे डी-मीलस्टोन करने जा रहा हूं। हम v3.7 . के बाद पुनर्मूल्यांकन कर सकते हैं

आप लोगों पर निर्भर है, लेकिन मैं यह सुनिश्चित करना चाहता हूं कि आप स्पष्ट हैं कि यह समवर्ती समर्थन जोड़ने के लिए टिकट नहीं है। असली मुद्दा यह है कि एक एकल धारावाहिक वर्तमान वास्तुकला में एक पुट और पोस्ट दोनों को सही ढंग से मान्य नहीं कर सकता है। Concurrency ने अभी "असफल परीक्षण" प्रदान किया है।

TL; DR आप टॉम के प्रस्तावित फिक्स पर शुरू करके देख सकते हैं कि यह समस्या क्यों अवरुद्ध है।

संक्षेप में, प्रस्तावित समाधान PUT अनुरोध के लिए आवश्यक सभी फ़ील्ड बनाना है। इस दृष्टिकोण के साथ (कम से कम) दो समस्याएं हैं:

1. सीरियलाइज़र क्रियाओं में सोचते हैं कि HTTP तरीके नहीं हैं इसलिए एक-से-एक मैपिंग नहीं है। स्पष्ट उदाहरण create है क्योंकि इसे PUT और POST द्वारा साझा किया गया है। ध्यान दें कि create-by- PUT डिफ़ॉल्ट रूप से अक्षम है इसलिए प्रस्तावित सुधार शायद कुछ नहीं से बेहतर है।
2. हमें PUT (#3648, #4703 द्वारा साझा की गई भावना) में सभी फ़ील्ड की आवश्यकता नहीं है। यदि एक शून्य क्षेत्र अनुपस्थित है, तो हम जानते हैं कि यह कोई नहीं हो सकता है। यदि डिफ़ॉल्ट वाला कोई फ़ील्ड अनुपस्थित है, तो हम जानते हैं कि हम डिफ़ॉल्ट का उपयोग कर सकते हैं। PUT वास्तव में POST जैसी ही (मॉडल-व्युत्पन्न) फ़ील्ड आवश्यकताएं हैं।

असली मुद्दा यह है कि हम लापता डेटा और #3648, #4703 में मूल प्रस्ताव को कैसे संभालते हैं, और यहां सही समाधान है। यदि हम if_missing_use_default जैसी अवधारणा पेश करते हैं तो हम सभी HTTP मोड (क्रिएट-बाय- PUT सहित) का समर्थन कर सकते हैं। मेरे मूल प्रस्ताव ने इसे partial के प्रतिस्थापन के रूप में प्रस्तुत किया, लेकिन इसे ऑर्थोगोनल अवधारणा के रूप में सोचना आसान (और आवश्यक हो सकता है)।

अगर हम if_missing_use_default जैसी अवधारणा पेश करते हैं।

किसी को भी इसे लागू करने से रोकने के लिए कुछ भी नहीं है, या एक सख्त "सभी क्षेत्रों की आवश्यकता है" एक आधार धारावाहिक वर्ग के रूप में, और इसे तीसरे पक्ष के पुस्तकालय के रूप में लपेटता है।

मेरी राय यह है कि सख्त "सभी क्षेत्रों की आवश्यकता होती है" मोड भी इसे कोर में बनाने में सक्षम हो सकता है, यह बहुत स्पष्ट स्पष्ट व्यवहार है, और मैं देख सकता हूं कि यह उपयोगी क्यों होगा।

मुझे विश्वास नहीं है कि "फ़ील्ड को वैकल्पिक होने की अनुमति दें, लेकिन मॉडल डिफ़ॉल्ट का उपयोग करके सब कुछ प्रतिस्थापित करें, यदि वे मौजूद हैं" - ऐसा लगता है कि यह कुछ बहुत ही काउंटर-सहज ज्ञान युक्त व्यवहार पेश करेगा (उदाहरण के लिए "बनाया_एट" फ़ील्ड, जो स्वचालित रूप से समाप्त हो जाता है खुद को अपडेट कर रहे हैं)। यदि हम कठोर व्यवहार चाहते हैं, तो हमें केवल कठोर व्यवहार करना चाहिए।

किसी भी तरह से, इस तक पहुंचने का सही तरीका यह है कि इसे तीसरे पक्ष के पैकेज के रूप में मान्य किया जाए, फिर हमारे दस्तावेज़ अपडेट करें ताकि हम उससे लिंक कर सकें।

वैकल्पिक रूप से, यदि आप आश्वस्त हैं कि हम मूल से एक व्यवहार को याद कर रहे हैं जिसकी हमारे उपयोगकर्ताओं को वास्तव में आवश्यकता है, तो व्यवहार और दस्तावेज़ीकरण को अद्यतन करने के लिए एक पुल अनुरोध करने के लिए आपका स्वागत है, ताकि हम गुणों का आकलन कर सकें ठोस तरीका।

इसके लिए शुरुआती बिंदु के रूप में पुल अनुरोधों को लेने में खुशी हुई, और इस व्यवहार को प्रदर्शित करने वाले तीसरे पक्ष के पैकेज को शामिल करने में भी खुशी हुई।

पुट-इज़-सख्त व्यवहार का विकल्प रखने में मूल्य के आसपास आ रहा है।

यह अभी भी खड़ा है। मुझे लगता है कि हम उस पहलू पर मूल रूप से विचार कर सकते हैं, अगर कोई उन पंक्तियों के साथ पुल अनुरोध करने के लिए पर्याप्त परवाह करता है। इसे एक वैकल्पिक व्यवहार होना चाहिए।

ऐसा लगता है कि यह कुछ बहुत ही प्रति-सहज ज्ञान युक्त व्यवहार प्रस्तुत करेगा (उदाहरण के लिए "बनाया_एट" फ़ील्ड, जो स्वचालित रूप से स्वयं को अपडेट करना समाप्त कर देता है)।

एक created_at फ़ील्ड read_only (या धारावाहिक से बाहर रखा जाना चाहिए) होना चाहिए। इन दोनों मामलों में, यह अपरिवर्तित रहेगा (सामान्य धारावाहिक व्यवहार)। काउंटर-सहज ज्ञान युक्त मामले में कि फ़ील्ड केवल सीरिएलाइज़र में पढ़ने के लिए नहीं है, आपको स्वचालित रूप से इसे बदलने का प्रति-सहज ज्ञान युक्त व्यवहार मिलेगा।

इसके लिए शुरुआती बिंदु के रूप में पुल अनुरोधों को लेने में खुशी हुई, और इस व्यवहार को प्रदर्शित करने वाले तीसरे पक्ष के पैकेज को शामिल करने में भी खुशी हुई।

बिल्कुल। "डिफ़ॉल्ट का उपयोग करें" भिन्नता तीसरे पक्ष के पैकेज के लिए एक आदर्श मामला है क्योंकि परिवर्तन मौजूदा व्यवहार के चारों ओर एक छोटा आवरण है (एक विधि) और (यदि आप डिफ़ॉल्ट तर्क में खरीदते हैं) सभी गैर-आंशिक धारावाहिकों के लिए काम करता है।

4 घंटे पहले tomchristie ने इसे बंद कर दिया

शायद आप "पीआर वेलकम" या "तृतीय पक्ष प्लगइन" जैसे लेबल जोड़ने और इस तरह के वैध/स्वीकृत मुद्दों को खोलने पर विचार करेंगे। मैं अक्सर यह देखने के लिए खुले मुद्दों की खोज करता हूं कि क्या कोई समस्या पहले ही रिपोर्ट की जा चुकी है और समाधान की दिशा में इसकी प्रगति हुई है। मैं बंद मुद्दों को "अमान्य" या "निश्चित" के रूप में देखता हूं। कुछ "वैध लेकिन बंद" मुद्दों को हजारों अमान्य/निश्चित मुद्दों में मिलाने से कुशल खोज को आमंत्रित नहीं किया जाता है (भले ही आप जानते हों कि वे वहां हो सकते हैं)।

शायद आप "पीआर वेलकम" या "तृतीय पक्ष प्लगइन" जैसे लेबल जोड़ने पर विचार करें।

यह काफी उचित होगा, लेकिन हम चाहते हैं कि हमारा इश्यू ट्रैकर प्रोजेक्ट पर ही सक्रिय या कार्रवाई योग्य कार्य को प्रतिबिंबित करे।

हमारे लिए यह वास्तव में महत्वपूर्ण है कि हम अपने मुद्दों को कसकर दायरे में रखने की कोशिश करें। प्राथमिकताओं को बदलने का मतलब यह हो सकता है कि हम कभी-कभी उन मुद्दों को फिर से खोलना चुनते हैं जिन्हें हमने पहले बंद कर दिया था। अभी मुझे लगता है कि यह "कोर टीम तत्काल भविष्य में इसे संबोधित करना चाहती है" से बाहर हो गया है।

यदि यह बार-बार आता है, और कोई तीसरा पक्ष समाधान नहीं होता है, तो शायद हम इसका पुनर्मूल्यांकन करेंगे।

इस तरह के वैध/स्वीकृत मुद्दों को खुला छोड़ना।

समस्या प्रबंधन शैली पर थोड़ा और संदर्भ - https://www.dabapps.com/blog/sustainable-open-source-management/