Django-rest-framework: Serializer DateTimeField में अनपेक्षित समयक्षेत्र जानकारी है

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

हाय @tomchristie ,

मुझे लगता है कि यह एक डीआरएफ बग है।
आईएमएचओ, डीआरएफ का प्राकृतिक उपयोग इसे डीजेंगो टेम्पलेटिंग जैसे आउटपुट के रूप में उपयोग करना है।
एक django टेम्पलेट में टाइमज़ोन सही ढंग से दिखाया गया है, क्यों drf serializer django टाइमज़ोन सेटिंग का सम्मान नहीं करता है?

नमस्ते,

fields.py में DatetimeField कक्षा में कोड को देखकर मुझे पता चलता है कि Django टाइमज़ोन सेटिंग केवल आंतरिक मूल्य ( to_internal_value() ) के लिए अच्छी तरह से माना जाता है।

मैंने देखा है कि इस तरह मॉडल सीरिएलाइज़र का उपयोग करना:

class MyModelSerializer(ModelSerializer):

    class Meta:
        model = MyModel
        depth = 1
        fields = ('some_field', 'my_date_time_field')

क्षेत्र के लिए my_date_time_field (जो मुझे लगता है कि यह एक डेटटाइमफिल्ड है :)) प्रतिनिधित्व के लिए समयक्षेत्र डिफ़ॉल्ट रूप से कोई नहीं है ( to_representation() )।

दूसरे शब्दों में, यदि मैं गलत नहीं हूं, तो Django टाइमज़ोन केवल तभी माना जाता है जब मान स्टोरेज बैकएंड में लिखा जाता है।

आईएमएचओ मुझे लगता है कि to_representation() का वापसी मूल्य इस तरह होना चाहिए:
return self.enforce_timezone(value).strftime(output_format)
Django USE_TZ सेटिंग के अनुसार।

मैं इसके लिए एक पुल अनुरोध लिखता हूं।

किआओ
Valentino

@vpistis इसकी समीक्षा करना आसान होगा यदि आप वर्तमान में देखे गए एपीआई व्यवहार का एक उदाहरण दे सकते हैं, और आप क्या देखना चाहते हैं (पहले कार्यान्वयन पहलुओं पर चर्चा करने के बजाय)

अपना TIME_ZONE = 'Asia/Kolkata' सेट करें और एकल डेटाटाइम फ़ील्ड, appointment साथ एक मॉडल सीरिएलाइज़र बनाएं।

बनाने/अपडेट करने के दौरान, भेजें:

{
    "appointment": "2016-12-19T10:00:00"
}

और वापस जाओ:

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

लेकिन अगर आप उस वस्तु को फिर से प्राप्त या सूचीबद्ध करते हैं, तो आपको मिलता है:

{
    "appointment": "2016-12-19T04:30:00Z"
}

निर्माण के दौरान, यदि Z निर्दिष्ट नहीं है, तो DRF मानता है कि ग्राहक TIME_ZONE द्वारा निर्दिष्ट समय क्षेत्र का उपयोग कर रहा है और उस समय क्षेत्र में स्वरूपित समय लौटाता है (अंत में +5:30 जोड़कर, जो वास्तव में अमान्य होगा यदि यह ग्राहक द्वारा प्रदान किया गया समय था)। यह शायद अधिक समझ में आता है यदि भविष्य की पहुंच भी उस समय क्षेत्र में स्वरूपित समय लौटाती है, इसलिए पुनर्प्राप्ति/सूची के दौरान प्रतिक्रिया निर्माण/अद्यतन के दौरान समान थी।

जब निर्माण/अद्यतन के दौरान पिछला Z प्रदान किया जाता है, तो कॉन्फ़िगर किए गए समयक्षेत्र में समय वापस करना है या नहीं, इसका भी सवाल है, जैसे कि भेजना:

{
    "appointment": "2016-12-19T04:30:00Z"
}

रिटर्न:

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

मैं इसके लिए रहूंगा, क्योंकि यह प्रतिक्रिया को सूचियों/पुनर्प्राप्ति के लिए प्रतिक्रिया के अनुरूप रखता है।

एक और विकल्प पूरी तरह से यूटीसी समय वापस करना होगा, यहां तक ​​​​कि सृजन/अपडेट के दौरान भी, लेकिन मुझे यह कम उपयोगी लगता है। किसी भी तरह से, हमारे पास अभी जो 50/50ish स्थिति है, उसके लिए लगातार टाइमज़ोन होना बेहतर होगा।

अपना TIME_ZONE = 'एशिया/कोलकाता' सेट करें और एकल डेटाटाइम फ़ील्ड, अपॉइंटमेंट के साथ एक मॉडल सीरिएलाइज़र बनाएं।

बनाने/अपडेट करने के दौरान, भेजें:

{
"नियुक्ति": "2016-12-19T10:00:00"
}
और वापस जाओ:

{
"नियुक्ति": "2016-12-19T10:00:00+5:30"
}
लेकिन अगर आप उस वस्तु को फिर से प्राप्त या सूचीबद्ध करते हैं, तो आपको मिलता है:

{
"अपॉइंटमेंट": "2016-12-19T04:30:00Z"
}

थैंक्स @ जोनाथन-गोलोरी यह सटीक व्यवहार है जिसे मैं वास्तव में देखता हूं।
मेरे लिए व्यवहार इस तरह होना चाहिए (@ जोनाथन-गोलोरी उदाहरण का उपयोग करके :)):

डिफ़ॉल्ट DATETIME_FORMAT के साथ बनाने/अपडेट करने के दौरान, भेजें:

{
    "appointment": "2016-12-19T10:00:00"
}

और वापस जाओ:

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

यदि आप उस वस्तु को फिर से प्राप्त या सूचीबद्ध करते हैं, तो आपको मिलता है:

{
    "appointment": "2016-12-19T10:00:00+5:30"
}

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

बहुत बहुत धन्यवाद @tomchristie

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

DRF 3.4.6 का उपयोग करने वाले प्रोडक्शन वेब ऐप के लिए, हमने इस समाधान के साथ समाधान किया है:
https://github.com/vpistis/django-rest-framework/commit/be62db9080b19998d4de3a1f651a291d691718f6

अगर कोई पुल अनुरोध सबमिट करना चाहता है जिसमें या तो शामिल है:

• बस असफल परीक्षण मामले शामिल हैं, या ...
• टेस्ट केस + फिक्स

यह सबसे स्वागत योग्य होगा।

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

थैंक्स

यदि आप वैश्विक परीक्षण सेटिंग्स को संशोधित करना चाह रहे हैं, तो वे यहां स्थित

यदि आप परीक्षण के दौरान सेटिंग्स को ओवरराइड करने का प्रयास कर रहे हैं, तो आप override_settings डेकोरेटर का उपयोग कर सकते हैं।

इस सुविधा की भी सराहना करेंगे। मुझे लगता है कि USE_TZ सेटिंग का सम्मान किया जाना चाहिए और मानों को मानक Django व्यवहार के समान परिवर्तित किया जाना चाहिए।

यहां पहला कदम एक असफल परीक्षण केस लिखना होगा जिसे हम वर्तमान परीक्षण सूट में जोड़ सकते हैं।
अगला कदम उस मामले के लिए एक फिक्स शुरू करना होगा :)

नमस्ते,
मेरे लिए यह इस सुविधा के लिए एक परीक्षण मामला है

class TestDateTimeFieldTimeZone(TestCase):
    """
    Valid and invalid values for `DateTimeField`.
    """
    from django.utils import timezone

    valid_inputs = {
        '2001-01-01 13:00': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        '2001-01-01T13:00': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        '2001-01-01T13:00Z': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        datetime.datetime(2001, 1, 1, 13, 00): datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()),
        datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.UTC()): datetime.datetime(2001, 1, 1, 13, 00,
                                                                                        tzinfo=timezone.get_default_timezone()),
        # Django 1.4 does not support timezone string parsing.
        '2001-01-01T13:00Z': datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone())
    }
    invalid_inputs = {}
    outputs = {
        # This is not simple, for now I suppose TIME_ZONE = "Europe/Rome"
        datetime.datetime(2001, 1, 1, 13, 00, tzinfo=timezone.get_default_timezone()): '2001-01-01T13:00:00+01:00',
        datetime.datetime(2001, 1, 1, 13, 00, ): '2001-01-01T13:00:00+01:00',
    }

    field = serializers.DateTimeField()

मेरे कांटे में मैं सही समय क्षेत्र my 3.6.2_tz_fix में समय प्राप्त करने के लिए कुछ चाल का उपयोग करता

मुझे आशा है कि यह मदद :)

मैं देख रहा हूं कि यह बंद है, लेकिन मैं drf 3.6.3 चला रहा हूं और मेरे पोस्टग्रेज डेटाबेस में मेरे पास यह टाइमस्टैम्प "2017-07-12 14:26: 00-06" है, लेकिन जब मुझे डाकिया का उपयोग करके डेटा मिलता है तो मुझे यह "टाइमस्टैम्प" मिलता है। : "2017-07-12T20:26:00Z"। मुझे लगता है कि यह -06 घंटे जोड़ रहा है।

मेरी django सेटिंग्स टाइमज़ोन TIME_ZONE = str(get_localzone()) सेट करने के लिए tzlocal का उपयोग करती हैं। तो स्टार्टअप पर टाइमज़ोन सेट है।

मैं एक बुनियादी मॉडलसेरियलाइज़र का उपयोग कर रहा हूँ

class SnapshotSerializer(serializers.ModelSerializer):
    class Meta:
        model = Snapshot
        resource_name = 'snapshot' 
        read_only_fields = ('id',)
        fields = ('id', 'timestamp', 'snapshot')

क्या मैं कुछ भूल रहा हूँ?

बंद नहीं, यह अभी भी खुला है :)
लाल "बंद बटन" जो आप देख रहे हैं वह संदर्भ मुद्दे के लिए है।
... और आप सही कह रहे हैं, "बग" अभी भी है ;(
मील का पत्थर 3.6.3 से 3.6.4 के रूप में बदल गया है।

ओह ठीक। शुक्रिया!

12 जुलाई 2017 को शाम 5:10 बजे, "वैलेंटिनो पिस्टिस" नोटिफिकेशन @github.com
लिखा था:

बंद नहीं, यह अभी भी खुला है :)
लाल "बंद बटन" जो आप देख रहे हैं वह संदर्भ मुद्दे के लिए है।
... और आप सही कह रहे हैं, "बग" अभी भी है ;(
मील का पत्थर 3.6.3 से 3.6.4 के रूप में बदल गया है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/encode/django-rest-framework/issues/3732#issuecomment-314923582 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AIMBTcx-6PPbi_SOqeLCjeWV1Rb59-Ohks5sNVJ0gaJpZM4G0aRE
.

नमस्ते,

मुझे यकीन नहीं है कि यह पूरी तरह से मूल प्रश्न से संबंधित है, लेकिन क्या डीआरएफ को https://docs.djangoproject.com/en/1.11/ref/utils/#django के अनुसार सेट किए गए किसी भी टाइमज़ोन ओवरराइड का सम्मान करना चाहिए

मेरे पास एक प्रणाली है जहां मेरे उपयोगकर्ता टाइमज़ोन से जुड़े हुए हैं, और एपीआई को बेवकूफ डेटाटाइम प्राप्त होता है। मैं उन डेटाटाइम्स को वर्तमान उपयोगकर्ता के टाइमज़ोन में बदलने में सक्षम होने की उम्मीद करता हूं, लेकिन मुझे लगता है कि ../rest_framework/fields.py डिफ़ॉल्ट टाइमज़ोन लागू कर रहा है (यानी django सेटिंग फ़ाइल से एक:

    def enforce_timezone(self, value):
        field_timezone = getattr(self, 'timezone', self.default_timezone())

        if (field_timezone is not None) and not timezone.is_aware(value):
            try:
                return timezone.make_aware(value, field_timezone)

[...]

    def default_timezone(self):
        return timezone.get_default_timezone() if settings.USE_TZ else None

क्या यह वास्तव में timezone.get_current_timezone() को वरीयता के रूप में उपयोग कर रहा है यदि एप्लिकेशन ने ओवरराइड सेट किया है, जैसे कि मेरे मामले में?

हाय @ रिचर्डफोरशॉ जो एक अलग मुद्दे की तरह लगता है, लेकिन एक ही बॉल पार्क निश्चित रूप से।

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

मेरा पहला विचार इससे परे है यह सुनिश्चित करना है कि आप सर्वर के कॉन्फ़िगर किए गए समय क्षेत्र पर निर्भर होने के बजाय एपीआई को समय क्षेत्र की जानकारी भेज रहे हैं। इसके अलावा मुझे यह भी सोचने की इच्छा है कि आपको क्लाइंट पर एक समय स्थानीयकृत करने के लिए तैयार रहने की आवश्यकता है।

लेकिन हां, यहां एक विसंगति है जिसे संबोधित किया जाना है। (क्या मैंने पीआर वेलकम का जिक्र किया? )

carltongibson/django-filter#750 यहां प्रासंगिक होना चाहिए। मैं मूल रूप से डीआरएफ पर django-filter के टाइमज़ोन हैंडलिंग पर आधारित हूं, इसलिए 750 में परिवर्तन आसानी से यहां लागू किया जा सकता है।

मेरी नौसिखिया के लिए खेद है, लेकिन वास्तव में यहाँ क्या समस्या है? मेरे psql डेटाबेस में टाइमस्टैम्प सही है और Django सही टाइमज़ोन का उपयोग करने के लिए तैयार है। क्या टाइमस्टैम्प को परिवर्तित न करने के लिए कोई DRF सेटिंग्स है?

हाय @michaelaelise - यदि आप डेटा के उदाहरण को देखते हैं (शीर्ष के पास):

1. वे टाइमज़ोन जानकारी के बिना डेटाटाइम भेज रहे हैं। (यह मेरी किताब में एक बुरा कदम है।)
2. सर्वर अपने स्थानीय समय क्षेत्र को लागू कर रहा है और यह वापस आता है (इस मामले में +5:30 )
3. लेकिन बाद में, जब आप इसे लाते हैं, तो यह यूटीसी ( Z , "ज़ुलु" के लिए मुझे लगता है) के रूप में वापस आता है।

इस धारणा पर कोई वास्तविक समस्या नहीं है

लेकिन यह थोड़ा असंगत है, निश्चित रूप से 2 और 3 का प्रारूप समान होना चाहिए? (भले ही एक ग्राहक, सही ढंग से, समकक्ष मूल्यों के रूप में स्वीकार करेगा।)

मैं इसे बंद करने के इच्छुक हूं।

• यहां कोई तर्क त्रुटि नहीं है।
  
  
  
  • ये एक ही समय हैं: "2016-12-19T10:00:00+5:30" और "2016-12-19T04:30:00Z" - कुछ हद तक, कौन परवाह करता है कि वे कैसे वापस आते हैं?
  
  
• इस प्रकार, यह ऐसा कुछ नहीं है जिसे मैं वास्तव में समय आवंटित करने का औचित्य साबित कर सकता हूं।
• टिकट 2 साल पुराना है और किसी ने पीआर की पेशकश नहीं की है।

मैं एक पीआर को देखकर खुश हूं लेकिन मुझे यकीन नहीं है कि मैं वास्तव में इसे एक _ओपन इश्यू_ मानना ​​​​चाहता हूं।

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

एक अंतिम बात।
क्या होगा यदि हम चाहते हैं कि "2016-12-19T10:00:00+5:30" लौटाया जाए क्योंकि हम अलग-अलग समय क्षेत्रों में मतदान उपकरण हैं।
क्या यह "RETURN_DATETIME_WITH_TIMEZONE" सेटिंग हो सकती है?

हम एज उपकरणों पर django/drf का उपयोग कर रहे हैं। तो डाला जा रहा सभी डेटाटाइम परवाह नहीं है कि यह बेवकूफ है या नहीं क्योंकि एज डिवाइस टाइमज़ोन कॉन्फ़िगर किया गया है और पोस्टग्रेस फ़ील्ड हमेशा उस डिवाइस डेटाटाइम के लिए सटीक होगा।

वर्तमान परिदृश्य में क्लाउड सर्वर को प्रत्येक डिवाइस के टाइमज़ोन को जानने की आवश्यकता होगी, शायद यह होगा कि काम को django/drf से क्लाउड ऐप को संभालने के लिए स्थानांतरित कर दिया जाए।

USE_TZ मानते हुए, DRF पहले से ही समय क्षेत्र की जानकारी के साथ दिनांक समय लौटा रहा है। तो यह पहले से ही वही कर रहा है जो आपको वहां चाहिए।

यहां एकमात्र मुद्दा यह है कि क्या एक ही डीटी को एक समय क्षेत्र या किसी अन्य के रूप में स्वरूपित किया गया है। (लेकिन वे अभी भी वही समय हैं।)

@carltongibson

यहां कोई तर्क त्रुटि नहीं है।
ये वही समय हैं: "2016-12-19T10:00:00+5:30" और "2016-12-19T04:30:00Z" - कुछ हद तक, कौन परवाह करता है कि वे कैसे वापस आते हैं?

आईएमएचओ यह समस्या है: लौटाई गई स्ट्रिंग!
मैं Django समय क्षेत्र सेटिंग्स का उपयोग करता हूं और सभी टेम्पलेट सही समय "2016-12-19T10:00:00+5:30" लौटाते हैं जैसे हमने उम्मीद की थी, लेकिन डीआरएफ नहीं। डीआरएफ वापसी "2016-12-19T04:30:00Z" ।
क्लाइंट में, जो मेरे आरईएसटी एपिस का उपभोग करता है, कोई तर्क नहीं है, कोई समय रूपांतरण या डेटाटाइम स्ट्रिंग व्याख्या नहीं है।
दूसरे शब्दों में, मैं उम्मीद करता हूं कि डीआरएफ प्रतिक्रिया से डेटाटाइम Django टेम्पलेट "प्रतिक्रिया" के समान है: सर्वर क्लाइंट के लिए सभी डेटा तैयार करता है और क्लाइंट केवल इसे दिखाता है।

वैसे भी, इस शानदार परियोजना के लिए आपके धैर्य, समर्थन और आपके महान कार्य के लिए बहुत-बहुत धन्यवाद!

@vpistis यहाँ मेरी बात सिर्फ यह है कि प्रतिनिधित्व की तारीख सही है, सिर्फ प्रतिनिधित्व की उम्मीद नहीं है। जैसे ही आप इसे मूल तिथि पर पार्स करते हैं, हालांकि आपकी भाषा इसे संभालती है, इसमें कोई अंतर नहीं है।

मैं उम्मीद करता हूं कि उपयोगकर्ता दिनांक स्ट्रिंग को दिनांक तक पार्स कर रहे हैं, हालांकि उनकी क्लाइंट भाषा कच्ची स्ट्रिंग का उपभोग करने के बजाय इसके लिए प्रदान करती है।

मैं स्वीकार करता हूं कि यदि आप कच्चे तार का सेवन कर रहे हैं तो आपकी अपेक्षाएं यहां पूरी नहीं होंगी। (लेकिन ऐसा न करें: कल्पना करें कि अगर हमने UNIX टाइमस्टैम्प भेजे हैं, तो आप उन कच्चे का उपभोग करने का कोई तरीका नहीं है। एक उचित दिनांक ऑब्जेक्ट में कनवर्ट करें, जो भी आपकी क्लाइंट भाषा में है।)

मैं इस पर पीआर लेने के लिए वास्तव में खुश हूं। (मैंने इसे अभी तक बंद नहीं किया है!)

लेकिन रिपोर्ट किए हुए लगभग दो साल हो चुके हैं और पहली टिप्पणी के नौ महीने बाद (आपकी, एक साल बाद)। किसी ने हमें असफल परीक्षण का मामला भी नहीं दिया है। यह किसी के लिए इतना महत्वपूर्ण नहीं हो सकता। ऐसे में इसे समय देना मुश्किल है।

(इस तरह मैं इसे इस आधार पर बंद करने के लिए इच्छुक हूं कि अगर कोई कभी आता है तो हम एक पीआर लेंगे)

हाय सब, इसे #5408 द्वारा ठीक किया जाना चाहिए। यदि आपके पास शाखा स्थापित करने और यह सत्यापित करने का समय है कि सब कुछ अपेक्षित रूप से काम कर रहा है, तो यह शानदार होगा। धन्यवाद!

मुझे लगता है कि इस मुद्दे को किसी तरह फिर से पेश किया गया था:

जब मैंने डिफ़ॉल्ट TZ को UTC से यूरोप/एम्स्टर्डम में बदल दिया, तो एक परीक्षण विफल हो गया और मैंने देखा कि DRF डिफ़ॉल्ट TZ से कुछ अलग करने के लिए क्रमबद्ध है

संपादित करें: समस्या परीक्षण/फ़ैक्टरी सेटअप से संबंधित थी।

आदर्श

class Something(StampedModelMixin):
    MIN_VALUE = 1
    MAX_VALUE = 500

    id = models.BigAutoField(primary_key=True)  # pylint: disable=blacklisted-name
    product_id = models.BigIntegerField(db_index=True)
    start_time = models.DateTimeField()
    end_time = models.DateTimeField()
    percentage = models.IntegerField()
    enabled = models.IntegerField()

फ़ैक्टरी

class SomethingFactory(factory.django.DjangoModelFactory):
    """ Base Factory to create records for Something

    """
    start_time = factory.Faker('date_time', tzinfo=get_default_timezone())
    end_time = factory.Faker('date_time', tzinfo=get_default_timezone())
    percentage = factory.Faker('random_int', min=1, max=500)
    enabled = factory.Faker('random_element', elements=[0, 1])

    class Meta:  # pylint: disable=missing-docstring
        model = Something

अध्याय परीक्षा

class TestSomething:
    def test__get__empty(self):
        # preparation of data
        series = SeriesFactory.create(product_id=2)
        SomethingFactory.create_batch(3, product_id=1)

        # prepare request params
        url = reverse('series-somethings', kwargs={'pk': series.pk})

        # call the endpoint
        response = self.client.get(url)

        # asserts
        assert response.data == []

    def test__get__single(self):
        # preparation of data
        series = SeriesFactory.create(product_id=1)
        old_somethings = SomethingFactory.create_batch(1, product_id=1)

        # prepare request params
        url = reverse('series-somethings', kwargs={'pk': series.pk})

        # call the endpoint
        response = self.client.get(url)

        # asserts
        assert SomethingSerializer(old_somethings, many=True).data == response.data

दृश्य

class SomethingElseView(APILogMixin, ModelViewSet):
    @action(detail=True, methods=['get'])
    def somethings(self, request, pk=None):
        """ GET endpoint for Somethings

        .. seealso:: :func:`rest_framework.decorators.action`
        """
        otherthings = self.get_object()
        something_qs = Something.objects.all()
        something_qs = something_qs.filter(product_id=otherthings.product_id)
        serializer = self.something_serializer_class(something_qs, many=True)
        return Response(serializer.data)

serializer

class SomethingSerializer(serializers.ModelSerializer):

    class Meta:
        model = Something
        list_serializer_class = SomethingListSerializer
        fields = '__all__'
        extra_kwargs = {
            'percentage': {'min_value': Something.MIN_VALUE,
                           'max_value': Something.MAX_VALUE}
        }
        read_only_fields = ('id',
                            'ts_activated',
                            'ts_created',
                            'ts_updated')

टेस्ट आईपीडीबी परिणाम

ipdb> old_somethings
[{'product_id': 1, 'start_time': datetime.datetime(2011, 7, 13, 1, 10, 33, tzinfo=<DstTzInfo 'Europe/Amsterdam' LMT+0:20:00 STD>), 'end_time': datetime.datetime(2003, 3, 10, 9, 31, tzinfo=<DstTzInfo 'Europe/Amsterdam' LMT+0:20:00 STD>), 'percentage': 103, 'enabled': 0}]
ipdb> response.data
[OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:16:33'), ('ts_updated', '2019-02-27 14:16:33'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])]

परीक्षा परिणाम

E       AssertionError: assert [OrderedDict(...nabled', 0)])] == [OrderedDict([...nabled', 0)])]
E         At index 0 diff: OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 01:10:33'), ('end_time', '2003-03-10 09:31:00'), ('percentage', 103), ('enabled', 0)]) != OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])
E         Full diff:
E         - [OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 01:10:33'), ('end_time', '2003-03-10 09:31:00'), ('percentage', 103), ('enabled', 0)])]
E         ?                                                                                                                                                       ^^^^^^^^^^                          ^^^^^^^^^^^
E         + [OrderedDict([('id', 1), ('ts_created', '2019-02-27 14:38:15'), ('ts_updated', '2019-02-27 14:38:15'), ('product_id', 1), ('start_time', '2011-07-13 02:50:33'), ('end_time', '2003-03-10 10:11:00'), ('percentage', 103), ('enabled', 0)])]
E         ?

ढेर:

Django==2.0.10
djangorestframework==3.9.0
factory-boy==2.11.1
Faker==0.8.18
pytz==2018.9

हाय @ diegueus9 - क्या आप इसे एक सरल परीक्षण मामले में कम कर सकते हैं? आप क्रमानुसार नकली डेटा की तुलना किसी दृश्य के प्रतिसाद डेटा से कर रहे हैं। तो यह स्पष्ट नहीं है कि वास्तविक अपेक्षित मूल्य क्या है। मैं कुछ परिणामों की तुलना हार्डकोडेड मान से करने की अनुशंसा करता हूं। उदाहरण के लिए,

assert SomethingSerializer(old_somethings, many=True).data == {'blah':'blah'}

@rpkilby आपके उत्तर के लिए धन्यवाद। यह मेरी गलती थी, मेरे यूनिट परीक्षणों में समस्या यह है कि मैं डीबी से ताज़ा किए बिना इसके लिए फ़ैक्टरी-बॉय/फ़ेकर का उपयोग कर रहा था, इसलिए अंतर, मैंने अभी जोड़ा

    for old_something in old_somethings:
        old_something.refresh_from_db()

क्या मुझे अपनी पिछली टिप्पणी को हटा देना चाहिए या क्या मुझे इसे छोड़ देना चाहिए यदि कोई अन्य व्यक्ति भी उसी झूठी सकारात्मक का अनुभव करता है?

हाय @ diegueus9 , कोई चिंता नहीं - मैंने कोड को details टैग में छुपाया है।