좋아, 곧 있을 3.4 릴리스가 우선 순위이므로 이 매우 심층적인 티켓을 즉시 검토할 수 있을 것이라고 약속할 수 없습니다. 그러나 문제를 통해 상세하고 잘 생각해 주셔서 감사합니다. 이것은 며칠이나 몇 달이 아니라 몇 주 단위로 보는 것과 같습니다. 진행 상황이 더 이상 생각나면 티켓을 업데이트하고 계속 알려주시기 바랍니다.

확인. 내 문제는 두 가지 요소의 조합이라고 확신합니다.

1. DRF 에는 기본값(버전=0)이 있기 때문에 PUT의 필드가 필요하지 않습니다(모델에 필요하더라도).
2. DRF 는 PUT 필드를 현재 개체와 병합합니다(기본값을 주입하지 않음).

결과적으로 DRF는 현재(데이터베이스) 값을 사용하고 동시성 제어를 중단합니다. 문제의 후반부는 #3648(위에서도 인용됨)의 토론과 관련이 있으며 #1445에는 여전히 관련이 있는 것으로 보이는 (3.x 이전) 토론이 있습니다.

기본 동작이 비뚤어진 구체적인(그리고 점점 더 일반적인) 경우가 ModelSerializer의 "이상적인" 동작에 대한 논의를 재개하기에 충분하기를 바랍니다. 분명히, 나는 DRF에 대해 1인치밖에 안되지만 내 직관은 다음 동작이 필수 필드 및 PUT에 적합하다는 것입니다.

• 부분적이지 않은 직렬 변환기를 사용할 때 값을 받거나 기본값을 사용하거나(기본값이 없는 경우) 유효성 검사 오류를 발생시켜야 합니다. 모델 전체 유효성 검사는 입력/기본값에만 적용해야 합니다.
• 부분 직렬 변환기를 사용할 때 값을 받거나 현재 값에 대한 폴백(fallback)을 해야 합니다. 모델 전체의 유효성 검사는 결합된 데이터에 적용되어야 합니다.
• 나는 현재의 "non-partial" 직렬 변환기가 실제로 준 부분적이라고 생각합니다.
  
  
  
  • 필수이며 기본값이 없는 필드의 경우 부분적이지 않습니다.
  
  
  • 필수이며 기본값이 있는 필드의 경우 부분적입니다(기본값이 사용되지 않기 때문에).
  
  
  • 필요하지 않은 필드의 경우 부분적입니다.
  
  

위의 글머리 기호(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님 감사합니다. 그것은 나를 생산 지점에 머물게 할 것입니다.

"자고" 난 후에 주름이 하나 더 있다는 것을 깨달았습니다. 내가 말한 모든 것은 직렬 변환기의 필드에 적용되어야 합니다. 필드가 직렬 변환기에 포함되지 않은 경우 수정하면 안 됩니다. 이런 식으로 모든 직렬 변환기는 포함되지 않은 필드에 대해 부분적입니다(그리고 그래야만 합니다). 이것은 위의 "새 인스턴스 만들기"보다 조금 더 복잡합니다.

나는 이 문제가 앞으로 나아가기 위해 더 제한적인 제안으로 축소되어야 한다고 생각합니다.
현재 상태에서 실행 가능한 것으로 보입니다.
지금은 이것을 닫고 있습니다. 누군가가 원하는 행동에 대한 간결하고 실행 가능한 설명으로 줄일 수 있다면 재고할 수 있습니다. 그때까지는 단순히 광범위하다고 생각합니다.

다음은 non-partial serializer에 대한 간결한 제안입니다.

1. 직렬 변환기에 나열되지 않거나(암시적 또는 명시적으로) 읽기 전용으로 표시된 필드의 경우 기존 값을 유지합니다.
2. 다른 모든 필드의 경우 사용 가능한 첫 번째 옵션을 사용합니다.
   
   
   
   1. 제출된 값으로 채우기
   
   
   2. blank 및/또는 null 에 의해 암시된 값을 포함하여 기본값으로 채우기
   
   
   3. 예외 발생
   
   

명확성을 위해 이 프로세스의 최종 제품에 대해 유효성 검사가 실행됩니다.

즉, 업데이트를 위해 모델 기본값이 없는 직렬 변환기 필드에 required=True 를 설정하시겠습니까?

내가 맞았어?

예(및 그 이상). 이것이 내가 partial (모든 필드는 선택 사항)와 non-partial (모든 필드는 필수)의 구분을 이해하는 방법입니다. non-partial 직렬 변환기가 필드를 필요로 하지 않는 유일한 경우는 기본값(좁거나 광범위하게 정의됨)이 있는 경우입니다. 값이 제공되지 않으면 직렬 변환기가 해당 기본값을 사용할 수 있기 때문입니다._

기울임꼴 섹션은 DRF가 현재 수행하지 않는 것이며 내 제안에서 더 중요한 변경 사항입니다. 현재 구현은 필드를 건너뜁니다.

나는 두 번째 제안이 섞여 있었지만 실제로 "기본값"이라는 아이디어에 얼마나 관대하고 싶은지에 대한 별도의 질문입니다. 현재 동작은 default 그렇게 취급된다는 점에서 "엄격"합니다. 필요한 데이터의 양을 _정말__ 줄이고 싶다면 blank=True 필드도 선택 사항으로 만들 수 있습니다... 부재 값이 공백 값이라고 가정합니다.

@claytondaley 이 방법으로 2배 이후로 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 를 사용하여 OOL 논리를 저장 작업(속해 있는 위치)에 넣습니다. 기본적으로 UPDATE... WHERE version = submitted_version . 이것은 원자적이므로 경쟁 조건이 없습니다. 그러나 직렬화 논리에 다음과 같은 결함이 있습니다.

• 기본값이 모델의 필드에 설정된 경우 DRF는 required=False 를 설정합니다. (유효한) 아이디어는 제출된 값이 없는 경우 DRF가 해당 기본값을 사용할 수 있다는 것입니다.
• 그러나 해당 필드가 없으면 DRF는 기본값을 사용하지 않습니다. 대신 제출된 데이터를 객체의 현재 버전과 병합합니다.

필드가 필요하지 않은 경우 사용할 기본값이 있기 때문에 그렇게 합니다. DRF는 기본값을 사용하지 않기 때문에 해당 계약을 이행하지 않습니다. 기존 값을 사용합니다.

근본적인 문제는 이전에 논의되었지만 멋지고 구체적인 사례가 없었습니다. OOL이 그 이상적인 경우입니다. 버전 필드의 기존 값은 항상 OOL을 전달하므로 버전을 생략하여 전체 OOL 시스템을 우회할 수 있습니다. 그것은 (분명히) OOL 시스템의 원하는 동작이 아닙니다.

@claytondaley

직렬 변환기에 OOL을 하드 코딩했습니다.

내가 그랬어? 필드 요구 사항 외에 직렬 변환기에서 OOL 논리를 찾았습니까?

경쟁 조건이 있기 때문에 이것은 잘못된 장소입니다.

Sry, 여기 경쟁 조건이 어디에 있는지 알 수 없습니다.

OOL 논리를 저장 작업(속한 위치)에 넣는 django-concurrency를 사용하고 있습니다.

나는 또한 django-concurrency 를 사용하고 있습니다 :) 하지만 직렬 변환기가 아닌 모델 수준입니다. 직렬 변환기 수준에서 다음을 수행하기만 하면 됩니다.

• _version 필드가 항상 필수인지 확인하십시오(필요한 경우).
• 직렬 변환기가 OOL 오류를 처리하는 방법을 알고 있는지 확인하십시오(이 부분은 생략했습니다).
• apiview가 OOL 오류를 처리하고 가능한 diff 컨텍스트로 HTTP 409를 발생시키는 방법을 알고 있는지 확인하십시오.

실제로 autor가 "수정하지 않음"으로 표시된 문제로 인해 django-concurrency 를 사용하지 않고 있습니다. obj.save(update_fields=['one', 'two', 'tree']) 를 사용하면 잘못된 관행을 발견하여 OOL을 우회하므로 패키지를 분기했습니다.

여기에 앞서 언급한 serializer의 누락된 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

죄송합니다. 나는 당신이하고있는 일을 파악하기 위해 당신의 코드를 읽지 않았습니다. 시리얼라이저를 봤습니다. 분명히 직렬 변환기를 해킹하여 문제를 해결할 수 있지만 그럴 필요는 없습니다. DRF 논리의 결함은 그 자체로 존재하기 때문입니다. 나는 단지 요점을 설명하기 위해 OOL을 사용하고 있습니다.

그리고 최신 버전의 django-concurrency에 대해 해당 코드를 시도해야 합니다( IGNORE_DEFAULT=False 사용). django-concurrency도 기본값을 무시했는데 패치를 제출했습니다. 정상적인 경우에 작동하도록 하기 위해 추적해야 하는 이상한 코너 케이스가 있었습니다.

해킹이 아니라 기본 기능 확장이라고 생각합니다. 이러한 기능 지원을 위한 최적의 장소는 django-concurrency 패키지라고 생각합니다.

나는 전체 문제 토론을 다시 읽었고 당신의 제안이 너무 광범위하고 많은 곳에서 실패할 것이라는 것을 발견했습니다(다른 조건에서 다른 소스의 기본값을 마술처럼 사용하기 때문에). DRF 3.x는 2.x보다 훨씬 쉽고 예측 가능하므로 그대로 유지합니다. :)

직렬 변환기(모델에 도달하기 전에)에서 깨졌기 때문에 모델 계층에서 이것을 고칠 수 없습니다. OOL을 제쳐두고... default 가 설정된 경우 필드가 필요하지 않은 이유는 무엇입니까?

부분적이지 않은 직렬 변환기는 (기본적으로) 모든 필드를 "요구"하지만 우리는 이것을 생략합니다. 버그인가요? 아니면 논리적인 이유가 있습니까?

내 코드 예제에서 볼 수 있듯이 _version 필드는 가능한 모든 경우에 항상 올바르게 필요합니다.

btw, 내가 https://github.com/gavinwahl/django-optimistic-lock 에서 모델 lvl 코드를 빌렸고 django-concurrency 에서 빌린 것이 아니라 거의 이유 없이 복잡하다는 것이 밝혀졌습니다.

... 그래서 버그는 "비부분 직렬 변환기가 일부 필드를 필수가 아닌 것으로 잘못 설정했습니다"입니다. 그게 대안입니다. 그것이 부분적이지 않은 직렬 변환기가 만드는 (암시적) 약속이기 때문입니다.

나는 그것을 인용할 수 있다:

기본적으로 직렬 변환기는 모든 필수 필드에 대한 값을 전달해야 하며 그렇지 않으면 유효성 검사 오류가 발생합니다.

이것은 필수 사항에 대해 아무 것도 말하지 않습니다(기본값이 제공되는 경우 제외).

(그리고 두 가지 다른 수준에 대해 이야기하고 있다는 것을 알지만 ModelSerializer는 해당 결정에 대한 책임을 지지 않는 경우 필드를 요구하지 않아야 합니다.)

요점을 잃은 것 같아요..

(그리고 두 가지 다른 수준에 대해 이야기하고 있다는 것을 알지만 ModelSerializer는 해당 결정에 대한 책임을 지지 않는 경우 필드를 요구하지 않아야 합니다.)

그게 무슨 문제야?

알겠습니다. 다른 각도로 시도해 보겠습니다.

• 내 모델의 모든 필드를 다루는 부분적이지 않은 모델 직렬 변환기(편집: 모든 기본값)가 있다고 가정합니다.

동일한 데이터로 CREATE 또는 UPDATE가 다른 개체를 생성해야 합니까(ID 제외)

정말 간단한 모델 및 직렬 변환기와 실패/예상 동작을 보여주는 몇 줄을 사용하여 아이디어를 설명할 수 있습니까?

오늘은 시간이 늦어져서 내일 정리하겠습니다... 하지만 깊이 들어갈수록 #3648이 non-partial serializer에 더 적합합니다. 그동안 ModelSerializer가 모델의 모든 필드를 요구하지 않는 이유는 무엇입니까? 당신의 논리가 나와 다를 수도 있습니다.

ModelSerializer는 경계 모델을 검사하고 필요한지 여부를 결정하지 않습니까?

나는 기계적으로 방법 을 의미하지 않습니다. non-partial Serializer의 기본 가정은 모든 것을 요구하는 것입니다(위에서 인용). get_field_kwargs 가 이 가정(특히 여기 )에서 벗어날 경우에는 타당한 이유가 있어야 합니다. 그 이유는 무엇입니까?

내가 선호하는 대답은 "제출된 값이 없으면 해당 기본값을 사용할 수 있기 때문에" 계속 제공하는 것입니다(그러나 DRF는 실제로 기본값을 사용해야 함). 내가 놓친 또 다른 대답이 있습니까? 기본값이 있는 필드가 필요하지 않은 이유는 무엇입니까?

분명히 저는 "완전한" 솔루션을 선호합니다. 그러나 두 번째 답변이 있음을 인정합니다. 기본적으로 이러한 필드를 요구할 수 있습니다. 그것은 (현재 임의적인) 특별한 경우를 제거합니다. 코드를 단순화/축소합니다. 내부적으로 일관성이 있습니다. 내 우려를 해결합니다.

기본적으로 non-partial serializer를 non-partial로 만듭니다.

이제 나는 적어도 당신이 의미하는 바를 알고 있습니다. 이러한 경우 ModelForm 동작이 무엇인지 확인했습니까? (모바일에서는 직접 할 수 없습니다)

Django 문서에 따르면 '공백'은 필드가 필수인지 여부를 제어합니다. 이 문제에는 관련 없는 의견이 많이 포함되어 있으므로 이 문제에 대해 별도의 티켓을 여는 것이 좋습니다. 내 생각에 modelserializer는 modelform: 빈 옵션 제어가 필요하고 'null'은 None이 허용 가능한 입력이고 'default'가 해당 논리에 영향을 미치지 않는지 알려줍니다.

두 번째 티켓을 열 의향이 있지만 공백에 비슷한 코드가 필요한지 걱정됩니다. django 토론 그룹 에서 :

기존 모델 양식과 작동하는 템플릿을 사용하는 경우 모델에 선택적 문자 필드를 추가하지만 HTML 템플릿에 해당 필드를 추가하지 못합니다(예: 인적 오류, 템플릿을 잊어버렸거나 템플릿 작성자에게 변경, 템플릿에 변경이 필요한지 깨닫지 못함), 해당 양식이 제출될 때 Django는 사용자가 누락된 필드에 대해 빈 문자열 값을 제공했다고 가정하고 이를 모델에 저장하여 기존 값을 지웁니다. .

일관성을 위해 우리는 계약의 후반부를 이행할 의무가 있으며 부재 값을 공백으로 설정합니다. 이것은 모델에 대한 참조 없이 공백을 채울 수 있기 때문에 문제가 약간 적지만 매우 유사합니다(내 생각에 #3648과 일치함).

@tomchristie 에 대해 간략한 정보를 제공할 수 있습니다. required 상태가 모델 필드 defaults 속성에 의존하는 이유는 무엇입니까?

필수 상태가 모델 필드 기본 속성에 의존하는 이유는 무엇입니까?

간단히 말해서: 모델 필드에 기본값이 있는 경우 입력으로 제공하는 것을 생략할 수 있습니다.

사실 나는 이 행동에 동의한다. 코드에도 불구하고 ModelForm은 동일한 작업을 수행합니다(생성된 html이 기본값을 제공함). DRF가 다른 논리라면 '기본값'은 절대 적용되지 않습니다. 이 문제를 해결했습니다.

@pySilver 실제로 다음은 ModelForm 동작입니다.

# 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 는 원칙적으로 동의합니다. 그러나 예상되는 동작은 무엇입니까?

• 생성할 때 기본값을 얻습니다(사소하지만 모두가 이것이 옳다는 데 동의합니다).
• 업데이트 시 무엇을 받아야 합니까?

업데이트시에도 기본값을 가져와야 할 것 같습니다. 부분적이지 않은 직렬 변환기가 두 경우에 다르게 작동해야 하는 이유를 모르겠습니다. 부분적이지 않다는 것은 "완전한" 레코드를 보내고 있음을 의미합니다. 따라서 완전한 기록을 교체해야 합니다.

업데이트 시 값이 제공되지 않으면 값이 변경되지 않을 것으로 예상합니다. 요점은 알지만 기본값으로 투명하게 덮어쓰는 것은 내 POV에서 직관적이지 않습니다.

(제가 생각하기에 모든 업데이트가 모든 필드에 대해 부분적 의미론을 갖는 것이 실제로 더 나을 것이라고 생각하는 경우 - PUT은 여전히 ​​멱등성이고 이는 중요한 측면이며 주어진 현재 동작을 변경하는 것이 어색할 수 있습니다)

나는 확실히 당신에게 선호도를 공유하지 않습니다. 의도적으로 다르게 만들지 않는 한 모든 인터페이스가 엄격하기를 원합니다. 그러나 PARTIAL 대 NON-PARTIAL 구분은 이미 (이론적으로) 우리 둘 다 원하는 것을 제공합니다.

나는 부분이 당신이 원하는대로 정확하게 행동한다고 ​​믿습니다.

• 업데이트는 100% 부분적입니다.
• CREATEs(내 생각에)는 default 및 blank (논리적 예외)와 관련하여 부분적입니다. 다른 모든 경우에는 모델/데이터베이스 제약 조건이 바인딩됩니다.

비 부분 직렬 변환기에서 일관성을 얻으려고합니다. 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'} 가 포함됩니다. 두 번째 PUT 후에 {'username': 'curly', 'role': 'admin'} 가 됩니다. 이것은 멱등성을 깨뜨리지 않습니까? (완전히 확실하지 않음 - 합법적으로 요청함)

편집하다:
나는 모두가 PATCH의 의미에 대해 같은 페이지에 있다고 생각합니다.

두 번째 PUT 후에는 {'username': 'curly', 'role': 'admin'}이 됩니다.

저는 개인적으로 역할이 기본값으로 다시 전환된다면 놀랄 것입니다 replace

아직 실제 문제가 발생한 적이 없습니다.

여기도 마찬가지지만 지금까지 우리 프로젝트는 PATCH에 의존했습니다. :)
즉, 동시성을 처리하기 위한 모델 버전 관리가 포함된 OP의 사용 사례는 나에게 의미가 있습니다. PUT이 기본값(값이 생략된 경우)을 사용하여 동시성 예외를 발생시킬 것으로 예상합니다.

직렬 변환기가 반드시 RESTful RFC를 따를 필요는 없다는 점을 인정하는 것으로 시작하겠습니다. 그러나 그들은 최소한 호환 가능한 모드를 제공해야 합니다. 특히 REST 지원을 제공하는 패키지에서는 더욱 그렇습니다.

내 원래 주장은 첫 번째 원칙에서 나온 것이지만 RFC (섹션 4.3.4)는 구체적으로 다음과 같이 말합니다(강조 추가됨).

POST와 PUT 메소드의 근본적인 차이점은 동봉된 표현에 대한 다른 의도로 강조됩니다. POST 요청의 대상 리소스는 리소스 자체의 의미에 따라 포함된 표현을 처리하기 위한 반면 PUT 요청의 포함된 표현 은 대상 리소스의 상태를 교체하는 것으로 정의됩니다.
...
페이로드가 부분적인 콘텐츠일 가능성이 있으므로 주어진 대상 리소스에 대한 PUT을 허용하는 원 서버는 Content-Range 헤더 필드([RFC7233]의 섹션 4.2)를 포함하는 PUT 요청에 대해 400(잘못된 요청) 응답을 보내야 합니다.

따라서 PUT은 부분적이어서는 안 됩니다( 여기도 참조). 그러나 PUT의 섹션도 다음과 같이 설명합니다.

PUT 메서드는 대상 리소스의 상태가 생성되거나 요청 메시지 페이로드에 포함된 표현에 의해 정의된 상태로 대체되도록 요청합니다. 주어진 표현의 성공적인 PUT은 동일한 대상 리소스에 대한 후속 GET이 200(OK) 응답으로 전송되는 동등한 표현을 초래할 것임을 제안합니다.

GET에 대한 요점(필수는 아니지만)은 내 "타협" 솔루션을 주장합니다. 공백/기본값을 삽입하는 것은 편리하지만 이 동작을 제공하지 않습니다. 관의 못은 아마도 이 솔루션이 의심을 불러일으킬 누락된 필드가 없기 때문에 혼란을 최소화한다는 것입니다.

분명히 PATCH는 부분 업데이트를 위한 지정 옵션이지만 부분 PUT이 아닌 "지침 세트"로 설명되어 항상 약간 짜증이 납니다. POST(4.3.3)의 섹션은 실제로 다음과 같이 말합니다.

POST 메서드는 대상 리소스가 리소스 고유의 특정 의미에 따라 요청에 포함된 표현을 처리하도록 요청합니다. 예를 들어 POST는 다음과 같은 기능에 사용됩니다.

• HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공합니다.

...

• 리소스의 기존 표현에 데이터 추가.

다음과 같은 이유로 부분 업데이트에 POST를 사용하는 것에 대한 주장이 있다고 생각합니다.

• 개념적으로 데이터를 수정하는 것은 추가하는 것과 다르지 않습니다.
• POST는 자체 규칙을 사용할 수 있으므로 해당 규칙은 부분 업데이트가 될 수 있습니다.
• 이 작업은 ID가 있으면 CREATE와 쉽게 구별할 수 있습니다.

DRF가 완전한 준수를 열망하지 않더라도 사양 PUT 작업(즉, 전체 개체 교체)과 호환되는 직렬 변환기가 필요합니다. 가장 간단한(그리고 가장 혼란스러운) 대답은 모든 필드를 요구하는 것입니다. 또한 PUT은 기본적으로 부분적이지 않아야 하고 부분 업데이트는 다른 키워드(PATCH 또는 POST)를 사용해야 한다고 제안합니다.

우리 앱을 drf3.4.x로 마이그레이션하는 동안 첫 번째 PUT 문제가 발생한 것 같습니다. :)

<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= 에서 값을 검색했습니다. 따라서 기본적으로 특정 필드를 업데이트하려고 하는 동안 해당 필드 중 일부를 파란색 기본값으로 덮어씁니다.

사용자 지정 ModelSerializer를 사용하고 있으므로 문제를 쉽게 해결할 수 있습니다.

@pySilver 최근 댓글 내용이 이해가 되지 않습니다.

@rpkilby "다음 요청을 받자... 멱등성이 깨지지 않는가?"

아니요, 각 PUT 요청은 여러 번 반복되어 동일한 상태가 될 수 있다는 점에서 멱등원입니다. 그렇다고 해서 상태의 다른 부분이 그 동안 수정된 경우 어떻게든 재설정된다는 의미는 아닙니다.

다음은 PUT 동작에 대한 몇 가지 다른 옵션입니다.

• required=False 또는 default 가 없는 필드는 필수입니다. (기존의)
• 모든 분야가 요구됩니다. (완전 업데이트의 더 엄격하고 밀접하게 정렬된 의미 체계는 POST에 대한 초기 생성 의미 체계보다 실제로 더 엄격하기 때문에 _하지만_ 어색합니다.)
• 필드가 필요하지 않습니다(즉, PATCH 동작을 미러링하기만 하면 됨)

_absolute_ 정답은 없다는 점을 분명히 하지만 현재로서는 가장 실용적인 행동을 취했다고 생각합니다.

POST 요청에 대해 제공할 필요가 없지만 이후에 PUT 요청에 대해 제공해야 하는 필드가 있는 경우 일부 사용 사례에서 문제가 될 수 있다고 생각합니다. 또한 PUT-as-create 자체가 유효한 작업이므로 POST와 다른 "요구 사항" 의미 체계가 있는 경우에도 이상합니다.

누군가가 이것을 발전시키고 싶다면 나는 _강력하게_ 다양한 기본 직렬 변환기 클래스를 구현하는 타사 패키지로 시작하는 것이 좋습니다. 그런 다음 직렬 변환기 설명서에서 해당 항목에 연결할 수 있습니다. 사례가 잘 만들어지면 미래의 어느 시점에서 기본 동작을 조정하는 것을 고려할 수 있습니다.

@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 에서 해결되었습니다.

$ ModelField 에 기본값이 있으므로 가지고 있는 예제의 직렬 변환기 필드에 default= 이 필요하지 않습니다.

@tomchristie 최소한 현재 PUT 동작이 RFC 사양이 아니라는 데 동의하십니까? 그리고 내 제안(모두 요구 또는 기본값 삽입)이 모두 그렇게 할 것이라고요?

@tomchristie 좋은 소식입니다!

ModelField에 기본값이 있으므로 가지고 있는 예제의 직렬 변환기 필드에 default=가 필요하지 않습니다.

예, 데모용으로 매우 명시적으로 만들고 싶었습니다.

@tomchristie 가 직렬 변환기 동작에 대해 따로 논쟁하지 않는다는 점에서 마침내 가라앉고 있습니다. 나는 그의 반대가 (암시적으로) 단일 직렬 변환기가 모든 REST 모드를 지원해야 한다는 요구 사항에서 비롯된 것이라고 생각합니다. 이것은 엄격한 직렬 변환기가 POST에 영향을 미치는 방식에 대한 그의 불만에서 나타납니다. REST 모드는 호환되지 않으므로 현재 솔루션은 단일 모드에 대한 사양이 아닌 직렬 변환기입니다.

그것이 이의 제기의 진정한 근원이라면 정면으로 받아들이도록 합시다. 단일 직렬 변환기가 어떻게 모든 REST 모드에 대한 사양 동작을 제공할 수 있습니까? 내 대답은 PARTIAL 대 NON-PARTIAL이 잘못된 수준에서 구현된다는 것입니다.

• 부분 직렬 변환기와 부분 직렬 변환기가 있습니다. 이 접근 방식은 모든 모드에 대한 사양 동작을 지원하기 위해 여러 직렬 변환기가 필요함을 의미합니다.
• 우리는 실제로 부분적 대 비-부분적 검증(또는 이와 같은 맥락에서)이 필요합니다. 다른 REST 모드는 직렬 변환기에서 다른 유효성 검사 모드를 요청해야 합니다.

문제를 분리하기 위해 직렬 변환기는 REST 모드를 알지 못하므로 타사 직렬 변환기로 구현할 수 없습니다. 대신 DRF는 추가 정보를 직렬 변환기에 전달해야 합니다(대략 replace=True PUT ). 직렬 변환기는 이것을 구현하는 방법을 결정할 수 있습니다(모든 필드가 필요하거나 기본값을 삽입해야 함).

분명히 이것은 대략적인 제안이지만 교착 상태를 깨뜨릴 수도 있습니다.

더욱이, PUT-as-create는 그 자체로 유효한 작업이므로 POST와 다른 "필수성" 의미 체계를 갖는다면 이상할 것입니다.

PUT으로 생성할 수 있다는 점에는 동의하지만 의미론이 동일하다는 점에는 동의하지 않습니다. PUT 는 특정 리소스에서 작동합니다.

PUT 메서드는 대상 리소스의 상태가 생성되거나 요청 메시지 페이로드에 포함된 표현에 의해 정의된 상태로 대체되도록 요청합니다.

따라서 의미 생성이 실제로 다르다고 생각합니다.

• 게시하다/citizen/ 은 SSN(사회 보장 번호)이 생성될 것으로 예상합니다.
• 놓다/citizen/<SSN> 로 특정 SSN에 대한 데이터를 업데이트합니다. 해당 SSN에 데이터가 없으면 생성됩니다.

"id"는 PUT의 URI에 포함되어야 하므로 필요에 따라 처리할 수 있습니다. 대조적으로 "id"는 POST에서 선택 사항입니다.

"id"는 PUT의 URI에 포함되어야 하므로 필요에 따라 처리할 수 있습니다. 대조적으로 "id"는 POST에서 선택 사항입니다.

물론. 나는 "PUT이 _all_ 필드를 엄격히 요구하도록 하라"의 제안된 변경이 PUT-as-create가 POST-as-create wrt와 다른 동작을 가짐을 의미한다는 사실을 구체적으로 언급하고 있었습니다. 필드가 필수인지 여부.

PUT-is-strict 행동의 옵션을 갖는 가치에 대해 이야기하고 있습니다.

(이 경우 _all_ 필드가 엄격하게 필수임을 적용하고, PATCH에서 _no_ 필드가 필수임을 적용하고, POST에 required= 플래그를 사용하십시오.)

단일 직렬 변환기가 어떻게 모든 REST 모드에 대한 사양 동작을 제공할 수 있습니까?

직렬 변환기가 인스턴스화되는 방식에 따라 생성, 업데이트 및 부분 업데이트를 구별할 수 있으므로 문제가 되지 않는다고 생각합니다.

PUT 또는 POST $ 를 사용하여 create 할 수 있다는 점을 이미 지적했습니다. 의미 체계와 요구 사항이 다르므로 create 는 REST 모드에 대해 불가지론적이어야 합니다. 나는 구별이 실제로 is_valid 의 일부로 발생한다고 생각합니다. 특정 유효성 검사 모드를 요청합니다.

• 현장 존재 검증(PATCH) 없음
• required 플래그 기반 유효성 검사(POST)
• 엄격한 현장 존재 검증(PUT)

키워드별 논리를 CRUD 작업에서 제외함으로써 직렬 변환기와 DRF 간의 결합도 줄입니다. 유효성 검사 모드를 구성할 수 있는 경우 완전히 범용이 됩니다(3개의 키워드에 대해 3개의 특정 경우만 구현하더라도).

이 기능에 대해 잘 설명하고 있습니다. :)

.is_valid()를 호출할 때 "유효성 검사 모드"가 다르다는 것은 일어나지 않을 격변입니다.

우리는 아마도 기존의 'partial=True' 단위 kwarg에 대응하는 'complete=True'를 고려할 _수_ 있습니다_. 그것은 현재 작동하는 방식에 충분히 쉽게 맞고 "엄격한 필드"의 경우를 계속 지원할 것입니다.

직렬 변환기가 이 문제를 해결하는 데 적합한 장소입니까? 이 요구 사항은 REST 키워드와 밀접하게 연결되어 있으므로 적용하기에 적합한 위치일 수 있습니다. 이 접근 방식을 지원하려면 직렬 변환기가 입력으로 허용하는 필드 목록만 노출하면 됩니다.

제쳐두고 ... Django의 관심사 분리 (할당)에 대한 좋은 논의가 어딘가에 있습니까? "왜 유효성 검사가 직렬화의 일부인지"와 같은 질문에 대한 답변을 모르기 때문에 Django 친화적인 답변으로 자신을 제한하는 데 문제가 있습니다. 1.9의 직렬화 문서에는 유효성 검사에 대한 언급조차 없습니다. 그리고 엄격하게 첫 번째 원칙에서 다음과 같이 보입니다.

1. 모델은 내부 일관성과
2. "보기"(이 경우 REST 모드 프로세서)는 해당 보기와 관련된 비즈니스 규칙(예: RFC)을 적용해야 합니다.

유효성 검사에 대한 책임이 사라지면 직렬 변환기는 100% 부분적(기본적으로)이 될 수 있으며 "읽기 전용"과 같은 I/O 규칙에 특화될 수 있습니다. 이 방법으로 빌드된 ModelSerializer는 다양한 보기를 지원합니다.

직렬 변환기가 이 문제를 해결하는 데 적합한 장소입니까?

예.

1.9의 직렬화 문서에는 유효성 검사에 대한 언급조차 없습니다.

Django의 기본 제공 직렬화는 Web APIS에 유용하지 않으며 실제로 고정 장치를 덤프하고 로드하는 데 제한됩니다.

당신은 Django와 DRF의 아키텍처 가정을 나보다 더 잘 알고 있으므로 방법에 대해서는 당신에게 말해야 합니다. 확실히 init kwarg는 그것에 대한 올바른 느낌을 가지고 있습니다... 직렬 변환기를 "주문형"으로 재구성합니다. 유일한 제한 사항은 "즉시" 재구성할 수 없다는 것입니다. 그러나 인스턴스가 일회용이라고 가정하므로 이것은 중요한 문제가 아닙니다.

나는 지금 이것을 디마일스톤(de-milestone)으로 할 것이다. v3.7 이후에 재평가할 수 있습니다.

여러분에게 달려 있지만 이것이 동시성 지원을 추가하기 위한 티켓이 아니라는 점을 분명히 하고 싶습니다. 실제 문제는 단일 직렬 변환기가 현재 아키텍처에서 PUT과 POST를 모두 올바르게 검증할 수 없다는 것입니다. 동시성은 "실패한 테스트"를 제공했습니다.

TL;DR Tom이 제안한 수정 사항 에서 시작하여 이 문제가 차단된 이유를 확인할 수 있습니다.

요약하면 제안된 솔루션은 PUT 요청에 필요한 모든 필드를 만드는 것입니다. 이 접근 방식에는 (적어도) 두 가지 문제가 있습니다.

1. 직렬 변환기는 HTTP 메서드가 아닌 작업으로 생각하므로 일대일 매핑이 없습니다. 명백한 예는 create PUT 및 POST 가 공유하기 때문에 create 입니다. PUT 에 의한 생성은 기본적으로 비활성화되어 있으므로 제안된 수정 사항이 없는 것보다 나을 수 있습니다.
2. PUT 의 모든 필드를 요구할 필요는 없습니다(#3648, #4703에서 공유하는 감정). nillable 필드가 없으면 None일 수 있습니다. 기본값이 있는 필드가 없으면 기본값을 사용할 수 있습니다. PUT 는 실제로 POST 와 동일한 (모델 파생) 필드 요구 사항을 갖습니다.

진짜 문제는 #3648, #4703에서 누락된 데이터와 기본 제안을 처리하는 방법이며 여기 에 올바른 솔루션이 남아 있습니다. if_missing_use_default 와 같은 개념을 도입하면 모든 HTTP 모드( PUT 포함)를 지원할 수 있습니다. 내 원래 제안 은 partial 의 대체품으로 제시했지만 직교 개념으로 생각하는 것이 더 쉽고 필요할 수도 있습니다.

if_missing_use_default와 같은 개념을 도입한다면.

누군가가 이것을 구현하거나 엄격한 "모든 필드 필요"를 기본 직렬 변환기 클래스로 구현하고이를 타사 라이브러리로 래핑하는 것을 방해하는 것은 없습니다.

내 생각에는 엄격한 "모든 필드 필요" 모드도 핵심으로 만들 수 있으며, 이는 매우 분명하고 명백한 동작이며 이것이 왜 유용한지 알 수 있습니다.

나는 "필드를 선택 사항으로 허용하지만 존재하는 경우 모델 기본값을 사용하여 모든 것을 교체합니다"라고 확신하지 않습니다. 이는 매우 직관적이지 않은 동작(예: "created_at" 필드, 자동으로 종료되는 스스로 업데이트). 우리가 더 엄격한 행동을 원한다면 더 엄격한 행동을 취해야 합니다.

어느 쪽이든, 이에 접근하는 올바른 방법은 타사 패키지로 유효성을 검사한 다음 해당 패키지에 연결할 수 있도록 문서를 업데이트하는 것입니다.

또는 사용자에게 정말 필요한 동작이 코어에서 누락되었다고 확신하는 경우 풀 요청을 하고 동작 및 문서를 업데이트하여 매우 신속하게 장점을 평가할 수 있습니다. 구체적인 방법.

풀 리퀘스트를 이를 위한 출발점으로 삼게 되어 기쁩니다. 이 동작을 시연하는 타사 패키지를 포함하게 되어 더욱 기쁩니다.

PUT-is-strict 행동의 옵션을 갖는 가치에 접근합니다.

이것은 여전히 ​​유지됩니다. 누군가가 그 라인을 따라 풀 리퀘스트를 할 만큼 충분히 신경을 쓴 다면 우리는 그 측면을 핵심적으로 고려할 수 있다고 생각합니다. 선택적 동작이어야 합니다.

그것은 매우 직관적이지 않은 동작을 나타내는 것 같습니다(예: 자동으로 업데이트되는 "created_at" 필드).

created_at 필드는 read_only 이어야 합니다(또는 직렬 변환기에서 제외). 이 두 경우 모두 변경되지 않습니다(일반 직렬 변환기 동작). 직렬 변환기에서 필드가 읽기 전용이 아닌 직관적이지 않은 경우 자동으로 필드를 변경하는 직관적이지 않은 동작을 얻게 됩니다.

풀 리퀘스트를 이를 위한 출발점으로 삼게 되어 기쁩니다. 이 동작을 시연하는 타사 패키지를 포함하게 되어 더욱 기쁩니다.

전적으로. "기본값 사용" 변형은 타사 패키지에 이상적인 경우입니다. 변경 사항은 기존 동작에 대한 간단한 래퍼(한 가지 방법)이고 (기본 인수를 구매하는 경우) 모든 비-부분 직렬 변환기에 대해 작동하기 때문입니다.

tomchristie가 4시간 전에 닫았습니다.

아마도 "PR Welcome" 또는 "3rd Party Plugin"과 같은 레이블을 추가하고 이와 같이 유효한/확인된 문제를 열어 두는 것을 고려할 수 있습니다. 나는 종종 문제가 이미 보고되었고 해결 과정이 진행 중인지 확인하기 위해 미해결 문제를 검색합니다. 닫힌 문제를 "잘못된" 또는 "고정된" 것으로 인식합니다. 몇 가지 "유효하지만 마감된" 문제를 수천 개의 유효하지 않거나 수정된 ​​문제에 혼합하는 것은 효율적인 검색을 유도하지 않습니다.

"PR Welcome" 또는 "3rd Party Plugin"과 같은 레이블을 추가하는 것을 고려할 수 있습니다.

충분히 합리적이지만 문제 추적기가 프로젝트 자체에 대한 활성 또는 실행 가능한 작업을 반영하기를 바랍니다.

문제의 범위를 엄격하게 유지하려고 노력하는 것이 정말 중요합니다. 우선 순위를 변경한다는 것은 이전에 닫았던 문제를 다시 열겠다고 선택하는 것을 의미할 수 있습니다 . 지금 당장은 이것이 "핵심 팀이 가까운 장래에 이 문제를 해결하고자 하는 것"에서 벗어났다고 생각합니다.

그것이 반복적으로 나타나고 제3자 솔루션이 계속 없다면 아마도 우리는 그것을 재평가할 것입니다.

이와 같이 유효한/확인된 문제를 열어 둡니다.

문제 관리 스타일에 대한 추가 정보 - https://www.dabapps.com/blog/sustainable-open-source-management/