Django-tastypie: SHOW और INDEX क्रियाओं के लिए विभिन्न क्षेत्र

+1
मैं इस सुविधा के लिए गहराई से उम्मीद कर रहा हूं: "विस्तार क्षेत्र" और "सूची क्षेत्र" को अलग किया जा सकता है

+1 (#44 पर डुप्लीकेट के माध्यम से)

मुझे ऐसा लगता है कि दो चीजें हैं जो इंडेक्स क्रियाओं में डेटा का सबसेट प्राप्त करना आसान बना सकती हैं:

1. फुल_डीहाइड्रेट को इंडेक्स के लिए विभिन्न क्षेत्रों का उपयोग करें और विधियाँ प्राप्त करें। शायद कुछ ऐसा:

मेटा:
index_exclude_fields = ['some_m2m_field']

यह हमें कुछ डीबी क्वेरी को सहेजने की अनुमति देगा।

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

मैंने मूल्यांकन नहीं किया 1. कैशिंग पर असर पड़ेगा।
तुम क्या सोचते हो?

#48 में भी ठगा गया, लेकिन प्रत्येक मुद्दे के सार्थक पहलू हैं।

अगर मैं कर सकता तो मैं इस सुविधा को आगे बढ़ाना चाहता था, लेकिन मैं बहुत आगे निकल गया हूं। किसी भी तरह बेहतर फ़ाइल समर्थन के लिए इसे वहां रहने की आवश्यकता होगी, इसलिए इसे संबोधित करना होगा। इस पर 1.0 का लक्ष्य रखेंगे।

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

&आकार=[पूर्ण|सरल|कोई नहीं]

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

+1

मैं इस विचार का उल्लेख यहां पहले करूंगा क्योंकि यह इस मुद्दे के लिए प्रासंगिक लगता है, लेकिन इसे अपने आप में बंद करने की आवश्यकता हो सकती है।

यदि विभिन्न क्षेत्रों को दिखाने के लिए एक तंत्र विकसित किया जाता है, तो यह उपयोगी होगा यदि इसे प्रमाणीकरण के साथ भी एकीकृत किया जा सके। अधिक/कम क्षेत्रों को उजागर करने में सक्षम होना उपयोगकर्ता की अनुमतियों पर निर्भर करता है जो बहुत शक्तिशाली होगा। यदि यह पहले से ही संभव है, तो मुझे इसका कोई उल्लेख नहीं मिला है।

+1

+1

+1

+1

+1

+1

+1

मैं सूची/विवरण के अतिरिक्त प्रति विधि (POST, PUT, GET) पर प्रदर्शित फ़ील्ड (या तो फ़ील्ड या बहिष्कृत का उपयोग करके) को नियंत्रित करने में सक्षम होने की अपेक्षा करता हूं।

यहां एक समाधान है, नीचे दिया गया उदाहरण देखें: आप मूल मॉडल के संसाधन मॉडल (उदाहरण में UserResource) से कुछ भी बाहर नहीं करते हैं, इसलिए यह इसके अनुक्रमणिका दृश्य में भरा होगा। आपको मॉडल रिसोर्स की डिहाइड्रेट विधि में जाना होगा जिसमें आपका उप मॉडल शामिल है (ब्लॉगपोस्ट रिसोर्स में लेखक शामिल है) और बंडल के तत्वों को हटा दें।

उदाहरण:

class BlogPostResource(ModelResource):
     author = fields.ForeignKey(UserResource, 'author', full=True)
     ....
     class Meta:
         ...

def dehydrate(self, bundle):
         del bundle.data['author'].data['field_you_dont_wanna_show_here']
         del bundle.data['author'].data['field_you_dont_wanna_show_here']
         return bundle

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

तुम क्या सोचते हो?

एक बहुत, बहुत गंदे वर्कअराउंड का उदाहरण: प्रोजेक्ट फ़ील्ड को list_view में नहीं दिखाता है, लेकिन यह डिटेल_व्यू में करता है, बिना संसाधन को एक्सेस किए, बिना हार्डकोडिंग के url प्राप्त करना सकारात्मक होना चाहिए, लेकिन इसे जांचने का समय नहीं है :

class CompanyResource(ModelResource):
       """
       Tastypie resource for Company
      """
       projects = fields.ToManyField('api.resources.ProjectResource',
                                  'projects',full=True)
       class Meta:
           queryset = Company.objects.all()
           resource_name = 'companies'

       def dehydrate(self, bundle):
           if bundle.request.path == "/api/v1/companies/":
               del bundle.data['projects']
           return bundle

+1

+1

+1

मैं ट्रेन में सवार होने की भी उम्मीद करूंगा , लेकिन ट्रेन का होना अच्छा होगा, लेकिन

    def dehydrate(self, bundle):
        if self.get_resource_uri(bundle) == bundle.request.path:
            print "Detail"

        if self.get_resource_uri(bundle) != bundle.request.path:
            print "Not Detail - Could be list or reverse relationship."

        return bundle

इसलिए मैंने इसे कुछ और सोचा और कुछ ऐसा लेकर आया जो मुझे वह करने देने के करीब आता है जो मुझे लगता है कि @bmihelac ढूंढ रहा था।

प्रदान किए गए उदाहरण @ashwoods का उपयोग करते हुए, मान लीजिए कि हम केवल प्रोजेक्ट फ़ील्ड प्रदर्शित करना चाहते हैं यदि यह एक विस्तृत प्रतिक्रिया थी:

class CompanyResource(ModelResource):
    """
    Tastypie resource for Company
    """

    class Meta:
        queryset = Company.objects.all()
        resource_name = 'companies'
        additional_detail_fields = {'projects': fields.ToManyField('api.resources.ProjectResource', 'projects',full=True)}

    def dehydrate(self, bundle):
        # detect if detail
        if self.get_resource_uri(bundle) == bundle.request.path:
            # detail detected, include additional fields
            bundle = self.detail_dehydrate(bundle)

        return bundle

    # detail_dehydrate is basically full_dehydrate
    # except we'll loop over the additional_detail_fields
    # and we won't want to do the dehydrate(bundle) at the end
    def detail_dehydrate(self, bundle):
        """
        Given a bundle with an object instance, extract the information from it
        to populate the resource.
        """
        # Dehydrate each field.
        # loop over additional_detail_fields instead
        #for field_name, field_object in self.fields.items():
        for field_name, field_object in self._meta.additional_detail_fields.items():
            # A touch leaky but it makes URI resolution work.
            if getattr(field_object, 'dehydrated_type', None) == 'related':
                field_object.api_name = self._meta.api_name
                field_object.resource_name = self._meta.resource_name

            bundle.data[field_name] = field_object.dehydrate(bundle)

            # Check for an optional method to do further dehydration.
            method = getattr(self, "dehydrate_%s" % field_name, None)

            if method:
                bundle.data[field_name] = method(bundle)

        # dehydrating the bundle will create an infinite loop
        #bundle = self.dehydrate(bundle)
        return bundle

+1, अभी के लिए @dericcrago से फिक्स का उपयोग करके।

+1

+1

#526 में आंशिक कार्यान्वयन, मुझे यकीन नहीं है कि मैं इस सब पर बेचा गया हूं और इसमें परीक्षण/दस्तावेज़ों की कमी है।

बस इस टिकट को देखा ... और ऊपर गोमेद द्वारा उल्लिखित 'आकार' दृष्टिकोण की तरह ...

सोच रहा था कि # 526 में मेरा समाधान थोड़ा सीमित था, अगर लोग अन्य मामलों में अलग-अलग 'आकार' चाहते थे ...

निर्जलीकरण के बाद खेतों को हटाने के सुझावों के लिए ... मेरा पूरा कारण पहली जगह में मूल्यों की गणना करने से बचना है।

हालांकि, विस्तार_डीहाइड्रेट हुक के लिए विचार सशर्त रूप से अधिक विवरण जोड़ने की अनुमति देता है, मुझे पसंद है।

ऐसा लगता है कि परीक्षण और दस्तावेज़ दोनों सहित दो संभावित कार्यान्वयन उपलब्ध हैं। मैंने #569 में से एक लिखा है और #538 भी समान कार्यक्षमता करता है (#538 use_in कॉल करने योग्य होने के बाद से थोड़ा अधिक लचीलेपन की अनुमति देता है)। मेरा कार्यान्वयन इस कार्यक्षमता को नियंत्रित करने के लिए meta विशेषताएँ जोड़ता है (जो वर्तमान fields विशेषता के अनुरूप है) जबकि #538 फ़ील्ड में एक विशेषता जोड़ता है। दोनों वैध लगते हैं, बस एक डिजाइन निर्णय है कि किस रास्ते पर जाना है। मेटा में जोड़ना मेरे लिए सुसंगत लगता है और इसका उपयोग करना आसान है क्योंकि कुछ फ़ील्ड स्वचालित रूप से उत्पन्न हो सकते हैं और उनके प्रारंभिक पैरामीटर को संशोधित करना संभव नहीं हो सकता है। एक अन्य विकल्प दोनों पुल अनुरोधों को संयोजित करना और use_in पैरामीटर को meta विशेषता के आधार पर स्वचालित रूप से सेट करने की अनुमति देना होगा, हालांकि ऐसा लगता है कि यह आवश्यक से अधिक जटिलता को जोड़ता है। मुझे संबंधित पुल अनुरोधों को इंगित करने के लिए @issackelly का धन्यवाद।

[चिल्लाते हुए क्योंकि मैं #५३८ के पीछे मूल कारण था, यह मेरे #५२६ की सफाई थी]
बहुत मायने रखता है ... मेटा दृष्टिकोण, वास्तव में, ModelResource, आदि के लिए बहिष्कृत सूची के साथ जेल होगा ...

जैसा कि मैंने एक और टिकट में कहा था, इस तरह का एक "सरल" समाधान होगा, आईएमएचओ, 1.0 रिलीज के लिए पर्याप्त ... "क्लाइंट चयन योग्य 'आकृतियों' जैसे अधिक जटिल समाधान के साथ शायद बाद में रिलीज के लिए वांछनीय हो .. .

@funkybob सहमत, निश्चित रूप से अधिक जटिल समाधान क्लाइंट पक्ष से सहायक होगा, लेकिन यह अच्छा होगा कि इस कार्यक्षमता में asap शामिल हो ताकि 1.0 जारी होने से पहले इसका उपयोग शुरू किया जा सके।

वास्तव में उत्पादन अनुप्रयोग में पीआर का उपयोग करना, मुझे वास्तव में # 538 द्वारा प्रदान की गई कॉलबैक की लचीलापन पसंद है। मेरे पास कुछ उपयोग के मामले हैं जहां मुझे अनुमति के आधार पर रनटाइम पर संसाधन छिपाना है।

#569 . का उपयोग करके यह मेरे लिए संभव नहीं होगा

हाय, कोई खबर? वह पीआर जीवन को इतना आसान बनाता है, धन्यवाद!

@dericcrago . द्वारा प्रदान की गई हैक के साथ जा रहे हैं

+1

एक साधारण समाधान जिसका मैं उपयोग कर रहा हूं वह है ऐसे क्षेत्रों को संपादित करने के लिए get_detail और get_list विधियों को ओवरराइड करना।
यह वास्तव में फ़ील्ड के लिए डेटा लाने और फिर इसे बंडल से हटाने के ऊपरी हिस्से को बचाता है, लेकिन मुझे यकीन नहीं है कि यह विधि थ्रेडसेफ है, क्योंकि ऐसा लगता है कि संसाधन ऑब्जेक्ट्स प्रत्येक एपीआई कॉल पर नहीं बनाए जाते हैं।
यह बहुत अच्छा होगा अगर कोई इस पर टिप्पणी कर सकता है।

यहाँ कोड है:

class ArticleResource(BaseModelResource):
    owner = fields.ToOneField(UserResource, 'owner', full=True)

    class Meta:
        resource_name = "articles"

    def get_list(self, request, **kwargs):
        self.fields.pop("comments", None)
        return super(ArticleResource, self).get_list(request, **kwargs)

    def get_detail(self, request, **kwargs):
        self.fields["comments"] = fields.ToManyField(CommentResource, 'comments', full=True)
        return super(ArticleResource, self).get_detail(request, **kwargs)

+1

एक और समाधान यह है कि विस्तार और सूची दृश्यों के लिए अलग-अलग संसाधन हों:

from tastypie.resources import ModelResource
from django.contrib.auth.models import User

# detail will show everything except password
class UserResourceDetail(ModelResource):
    class Meta:
        queryset = User.objects.all()
    excludes = ('password',)
    resource_name = 'user'

# list will only show username & date_joined (and exclude password)
class UserResource(UserResourceDetail):
    class Meta(UserResourceDetail.Meta):
        fields = ('username', 'date_joined')
    get_detail = UserResourceDetail().get_detail

# ... register & use UserResource

+1

@dnozay समाधान के लिए +1

+1 @dnozay , बहुत बढ़िया

ध्यान दें कि यदि आप चाहते हैं कि get_resource_uri उपयोगकर्ता विवरण दृश्य के साथ सही ढंग से काम करे, तो आपको UserResource परिभाषित होने के बाद निम्नलिखित जोड़ना होगा।

UserResourceDetail.get_resource_uri = UserResource().get_resource_uri

अन्यथा resource_uri सभी विवरण प्रतिक्रियाओं में खाली हो जाएगा।

संभावित रूप से संबंधित: #1265