Django-tastypie: SHOW 및 INDEX 작업에 대한 다른 필드

+1
나는 이 기능을 간절히 바라고 있다: "detail field"와 "list field"는 분리될 수 있다

+1(#44에서 복제를 통해)

인덱스 작업에서 데이터의 하위 집합을 더 쉽게 가져올 수 있는 두 가지가 있는 것 같습니다.

1. full_dehydrate가 index 및 get 메서드에 대해 다른 필드를 사용하도록 합니다. 아마도 다음과 같습니다.

메타:
index_exclude_fields = ['some_m2m_field']

이렇게 하면 일부 db 쿼리를 저장할 수 있습니다.

1. 탈수를 위해 추가 '방법' 매개변수를 전달하십시오. 이를 통해 인덱스에 필요하지 않은 일부 필드를 건너뛰는 것과 같이 번들을 사용자 정의할 수 있으며 일부 대역폭을 절약하고자 합니다.

나는 1. 캐싱에 영향을 미칠 것이라고 평가하지 않았습니다.
어떻게 생각하나요?

또한 #48에서 속았지만 각 문제에는 가치 있는 측면이 있습니다.

가능하면 이 기능을 해제하고 싶었지만 총력이 부족했습니다. 어쨌든 더 나은 파일 지원을 위해 거기에 있어야 하므로 해결해야 합니다. 이에 대해 1.0을 대상으로 합니다.

이에 대한 내 사용 사례를 조금 더 조사한 후 보기/목록 보기보다 더 유연한 것으로 구현하도록 제안하고 싶습니다. 내가 정말로 할 수 있어야 하는 것은 다음과 같은 쿼리스트링 플래그를 취하는 것입니다.

&shape=[전체|단순|없음]

출력이 사용자가 선택한 세부 수준을 반영하도록 합니다. 이를 해킹할 방법을 찾았지만 ModelResource 클래스가 생성될 때 필드가 포함/제외되기 때문에 나중에 응답 주기에서 사용할 수 있는 것을 변경할 수 있는 방법을 찾지 못했습니다. 더욱이 이러한 결정을 내리고자 하는 프로세스의 단계에서 요청 개체를 사용할 수 없습니다.

+1

이 문제와 관련이 있는 것 같기 때문에 여기에서 먼저 이 생각을 언급하겠습니다. 그러나 자체적으로 분리해야 할 수도 있습니다.

다른 필드를 표시하는 메커니즘이 개발되면 인증과도 통합될 수 있다면 유용할 것입니다. 더 많거나 적은 필드를 노출할 수 있다는 것은 사용자의 권한에 따라 매우 강력할 것입니다. 이것이 이미 가능하다면 그에 대한 언급을 찾을 수 없습니다.

+1

+1

+1

+1

+1

+1

+1

목록/세부 정보 외에도 메서드(POST, PUT, GET)별로 표시되는 필드(필드 또는 제외 사용)를 제어할 수 있기를 기대합니다.

해결 방법은 다음과 같습니다. 아래 예를 참조하세요. 원본 모델의 리소스 모델(예제에서는 UserResource)에서 아무 것도 제외하지 않으므로 인덱스 보기에서 가득 차게 됩니다. 하위 모델을 포함하는 modelresource의 탈수 방법(BlogPostResource에는 작성자가 포함됨)으로 이동하고 번들의 요소만 삭제해야 합니다.

예시:

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에 프로젝트 필드를 표시하지 않지만 리소스 자체에 액세스할 필요 없이 detail_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의 부분 구현, 모든 것이 판매되고 있는지 확실하지 않으며 테스트/문서가 부족합니다.

방금 이 티켓을 보았고... 또한 위의 onyxfish가 언급한 '모양' 접근 방식과 유사합니다.

사람들이 다른 경우에 다른 '모양'을 원할 경우를 대비하여 #526의 솔루션이 약간 제한적이라고 생각했습니다...

탈수 후 필드를 제거하라는 제안에 ... 내 모든 이유는 처음에 값을 계산하지 않는 것입니다.

그러나 조건부로 더 많은 세부 정보를 추가할 수 있도록 하는 detail_dehydrate 후크에 대한 아이디어가 마음에 듭니다.

테스트와 문서를 포함하여 두 가지 가능한 구현이 가능한 것 같습니다. #569에 하나를 작성했고 #538도 유사한 기능을 수행합니다(#538은 use_in 가 호출 가능하므로 좀 더 유연하게 허용합니다). 내 구현은 이 기능을 제어하기 위해 meta 속성을 추가하는 반면(현재 fields 속성과 일치함) #538은 필드에 속성을 추가합니다. 둘 다 유효한 것으로 보이며 어떤 방향으로 갈 것인지에 대한 설계 결정일 뿐입니다. 일부 필드는 자동으로 생성될 수 있고 초기화 매개변수를 수정하는 것이 불가능할 수 있다는 점을 감안할 때 메타에 추가하는 것이 일관성 있는 것으로 보이며 사용하기 더 쉽습니다. 또 다른 대안은 두 pull 요청을 결합하고 meta 속성을 기반으로 use_in 매개변수가 자동으로 설정되도록 허용하는 것이지만, 이는 API에 필요한 것보다 더 복잡함을 추가하는 것으로 보입니다. 관련 pull 요청을 지적해 주신 @issackelly 에게 감사드립니다.

[#538의 원래 원인은 내 #526을 정리하는 것이므로 소리를 지르십시오.]
많은 의미가 있습니다 ... Meta 접근 방식은 실제로 ModelResource 등에 대한 제외 목록을 사용하여 젤리를 만들 것입니다 ...

다른 티켓에서 말했듯이, 이와 같은 "단순한" 솔루션은 IMHO, 1.0 릴리스에 충분합니다... "클라이언트 선택 가능한 '모양'"과 같은 더 복잡한 솔루션은 이후 릴리스에 바람직할 수 있습니다. .

@funkybob 확실히 더 복잡한 솔루션이 클라이언트 측에서 도움이 될 것이라는 데 동의하지만 1.0이 릴리스되기 전에 사용할 수 있도록 이 기능을 최대한 빨리 포함하는 것이 좋습니다.

실제로 프로덕션 애플리케이션에서 PR을 사용하면서 #538에서 제공하는 콜백의 유연성이 정말 마음에 듭니다. 권한에 따라 런타임에 리소스를 숨겨야 하는 몇 가지 사용 사례가 있습니다.

이것은 # 569를 사용하여 불가능할 것입니다.

안녕하세요, 어떤 소식이 있습니까? 그 PR은 삶을 훨씬 더 쉽게 만듭니다. 감사합니다!

@dericcrago에서 제공하는 해킹으로 진행

+1

내가 사용하는 간단한 해결 방법은 이러한 필드를 편집하기 위해 get_detail & get_list 메서드를 재정의하는 것입니다.
이렇게 하면 실제로 필드에 대한 데이터를 가져온 다음 번들에서 삭제하는 오버헤드가 절약되지만 이 메서드가 스레드로부터 안전한지는 확실하지 않습니다. 리소스 개체가 모든 API 호출에서 생성되지 않는 것처럼 보이기 때문입니다.
누군가가 이것에 대해 논평할 수 있다면 좋을 것입니다.

코드는 다음과 같습니다.

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