さて、次の3.4リリースが優先されるため、このかなり詳細なチケットをすぐに確認できるとは約束できません。 しかし、このように詳細でよく考えられた問題に感謝します。 これは、おそらく数日や数か月ではなく、数週間のスケールで見られるようになります。 何か進歩があったら、自分でさらに考えてみてください。チケットを更新して、私たちに知らせてください。

わかった。 私の問題は2つの要因の組み合わせであると確信しています。

1. DRFにはデフォルト（バージョン= 0）があるため、PUTのフィールドは必要ありません（モデルでは必要ですが）。
2. DRFは、PUTフィールドを現在のオブジェクトとマージします（デフォルトを挿入せずに）

その結果、DRFは現在の（データベース）値を使用し、同時実行制御を解除します。 問題の後半は＃3648（上記でも引用）の議論に関連しており、＃1445にはまだ関連しているように見える（3.x以前の）議論があります。

ModelSerializerの「理想的な」動作についての議論を再開するには、デフォルトの動作が逆である具体的な（そしてますます一般的な）ケースで十分であることを期待しています。 明らかに、私はDRFについて1インチの深さしかありませんが、私の直感では、次の動作が必須フィールドとPUTに適しています。

• 非部分シリアライザーを使用する場合は、値を受け取るか、デフォルトを使用するか、（デフォルトが使用できない場合は）検証エラーを発生させる必要があります。 モデル全体の検証は、入力/デフォルトにのみ適用する必要があります。
• 部分シリアライザーを使用する場合は、値を受け取るか、現在の値にフォールバックする必要があります。 モデル全体の検証は、その結合されたデータに適用する必要があります。
• 現在の「非部分的」シリアライザーは、実際には準部分的であると思います。
  
  
  
  • 必須でデフォルトのないフィールドには部分的ではありません
  
  
  • 必須でデフォルトがあるフィールドの場合は部分的です（デフォルトは使用されないため）
  
  
  • 必須ではないフィールドの場合は部分的です
  
  

上記の箇条書き（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シリアライザーがフィールドを必要としないのは、デフォルト（狭義または広義）が存在する場合のみです。_値が指定されていない場合、シリアライザーはそのデフォルトを使用できるためです。_

イタリック体のセクションは、DRFが現在行っていないことであり、私の提案におけるより重要な変更です。 現在の実装では、フィールドをスキップするだけです。

私は2番目の提案を混ぜ合わせましたが、それは実際には、「デフォルト」のアイデアでどれだけ寛大になりたいかという別の質問です。 現在の動作は、 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をシリアライザーにハードコーディングしました。 競合状態があるため、これは間違った場所です。 （同じ以前のバージョンの）並列更新はすべてシリアライザーで渡されます...しかし、保存アクションで勝つのは1つだけです。

私はdjango-concurrencyを使用しています。これは、OOLロジックを保存アクション（それが属する場所）に配置します。 基本的にUPDATE... WHERE version = submitted_version 。 これはアトミックであるため、競合状態はありません。 ただし、シリアル化ロジックの欠陥が明らかになります。

• モデルのフィールドにデフォルトが設定されている場合、DRFはrequired=Falseを設定します。 （有効な）考え方は、値が送信されない場合、DRFはそのデフォルトを使用できるというものです。
• ただし、そのフィールドが欠落している場合、DRFはデフォルトを使用しません。 代わりに、送信されたデータをオブジェクトの現在のバージョンとマージします。

フィールドが不要な場合は、デフォルトで使用するため、必要になります。 DRFはデフォルトを使用しないため、その契約を履行しません...既存の値を使用します。

根本的な問題については前に説明しましたが、具体的な事例はありませんでした。 OOLはその理想的なケースです。 バージョンフィールドの既存の値は常にOOLを渡すため、バージョンを除外することでOOLシステム全体をバイパスできます。 これは（明らかに）OOLシステムの望ましい動作ではありません。

@claytondaley

OOLをシリアライザーにハードコーディングしました。

私はしましたか？ フィールド要件のほかに、私のシリアライザーにOOLロジックを見つけましたか？

競合状態があるため、これは間違った場所です。

申し訳ありませんが、ここでの競合状態がどこにあるのかわかりません。

私は、OOLロジックを（それが属する場所の）保存アクションに入れるdjango-concurrencyを使用しています。

私もdjango-concurrencyを使用しています:)しかし、それはモデルレベルであり、シリアライザーではありません。 シリアライザーレベルでは、次のことを行う必要があります。

• _versionフィールドが常に必須であることを確認してください（必要な場合）
• シリアライザーがOOLエラーの処理方法を知っていることを確認してください（この部分は省略しました）
• apiviewがOOLエラーを処理する方法を知っていることを確認し、可能な差分コンテキストでHTTP409を発生させます

実際、autorが「修正されない」とマークされた問題のためにdjango-concurrencyを使用していません。 obj.save(update_fields=['one', 'two', 'tree'])が使用されるとOOLをバイパスしますが、これは悪い習慣であることがわかったので、パッケージをフォークしました。

これが、前述のシリアライザーの欠落している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フィールドは、考えられるすべての場合に常に正しく必要です。

ところで、私はモデルレベルのコードをhttps://github.com/gavinwahl/django-optimistic-lockから借りたのであって、 django-concurrencyから借りたのではなく、ほとんど理由もなく複雑になっていることがわかりました。

...したがって、バグは「非部分的なシリアライザーが一部のフィールドを誤って不要に設定する」ことです。 それが代替手段です。 これは、非部分的なシリアライザーが行う（暗黙の）コミットメントだからです。

私はそれを引用することができます：

デフォルトでは、シリアライザーにはすべての必須フィールドの値を渡す必要があります。そうしないと、検証エラーが発生します。

これは必須については何も言いません（デフォルトが提供されている場合を除く）。

（そして、私は2つの異なるレベルについて話していると思いますが、ModelSerializerがその決定に責任を負わない場合は、フィールドの要件を解除するべきではありません）

私はあなたのポイントを失ったと思います。

（そして、私は2つの異なるレベルについて話していると思いますが、ModelSerializerがその決定に責任を負わない場合は、フィールドの要件を解除するべきではありません）

それの何がいけないの？

OK、別の角度で試してみましょう。

• モデルのすべてのフィールドをカバーする非部分的なモデルシリアライザー（編集：すべてのデフォルト）があると仮定します。

同じデータを使用したCREATEまたはUPDATEで、異なるオブジェクト（IDを除く）が生成された場合

いくつかの非常に単純なモデルとシリアライザー、および失敗した/予想される動作を示す数行を使用して、アイデアを説明できますか？

明日はここで遅くなっているので、何かをまとめます...しかし、深くなるほど、＃3648は非部分的なシリアライザーになります。 それまでの間、ModelSerializerがモデル内のすべてのフィールドを必要としないのはなぜですか？ たぶんあなたの論理的根拠は私のものとは異なります。

ModelSerializerは、制限されたモデルを検査し、それが必要かどうかを判断しますね。

私は機械的にどのように意味するのではありません。 非部分シリアライザーの基本的な前提は、すべてを要求することです（上記で引用）。 get_field_kwargsがこの仮定（具体的にはここ）から逸脱する場合は、正当な理由があるはずです。 その理由は何ですか？

私の好みの答えは、「値が送信されない場合はそのデフォルトを使用できるため」（ただし、DRFは実際にデフォルトを使用する必要があるため）私が提供し続けるものです。 私が見逃している別の答えはありますか？ デフォルトのフィールドが不要な理由は何ですか？

明らかに、私は「完全な」ソリューションを好みます。 しかし、私は2番目の答えがあることを認めます。 デフォルトでこれらのフィールドを要求できます。 これにより、（現在は任意の）特殊なケースが排除されます。 コードを簡素化/削減します。 それは内部的に一貫しています。 それは私の懸念に対処します。

基本的に、それは非部分的なシリアライザーを本当に非部分的にします。

今、私は少なくともあなたが何を意味するのかを知っています。 そのような場合のModelFormの動作を確認しましたか？ （モバイルでは自分でこれを行うことはできません）

Djangoのドキュメントによると、「空白」はフィールドが必須かどうかを制御します。 この問題には無関係なコメントがたくさん含まれているため、この問題については別のチケットを開くことをお勧めします。 私の意見では、modelserializerはmodelformのように機能する可能性があります。空白のオプションコントロールが必要です。「null」はNoneが受け入れ可能な入力であるかどうかを示し、「default」はそのロジックに影響を与えません。

2つ目のチケットを開くつもりですが、空白に同様のコードが必要になるのではないかと心配しています。 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には、デフォルトがある場合でも、この入力が必要です。 これは、内部的に一貫性のある2つの動作の1つです。

必要な状態がモデルフィールドのデフォルトプロパティに依存するのはなぜですか？

簡単に言うと、モデルフィールドにデフォルトがある場合は、入力としての提供を省略できます。

@tomchristieは原則的に同意します。 しかし、期待される動作は何ですか？

• 作成時に、デフォルトを取得します（些細なことですが、誰もがこれが正しいことに同意します）
• 更新時に、何を取得する必要がありますか？

更新時にもデフォルトを取得する必要があるように思われます。 非部分シリアライザーが2つのケースで異なる動作をする理由がわかりません。 非部分的とは、「完全な」レコードを送信していることを意味します。 したがって、完全なレコードを置き換える必要があります。

更新時に提供されない場合、値は変更されないと思います。 要点はわかりますが、デフォルト値で透過的に上書きすると、POVからは直感に反します。

（どちらかといえば、すべての更新がすべてのフィールドの部分的なセマンティクスである方が実際にはおそらく良いと思います-PUTは依然としてべき等であり、これは重要な側面であり、現在の動作を変更するのはおそらく厄介です）

私は確かにあなたの好みを共有しません。 意図的に別の方法で作成しない限り、すべてのインターフェイスを厳密にしたいと思います。 ただし、PARTIALとNON-PARTIALの区別は、（理論的には）両方が必要とするものをすでに提供しています。

私は部分的にあなたが望むように正確に振る舞うと信じています：

• 更新は100％部分的です
• CREATE（私が推測する）はdefaultとblank （論理例外）に関して部分的です。 他のすべての場合、モデル/データベースの制約がバインドされます。

非部分シリアライザーで一貫性を確保しようとしています。 defaultの特殊なケースを排除すると、既存の非部分シリアライザーが厳密なシリアライザーになります。 また、ModelFormと同等になります。

これによりプロジェクト内に小さな不連続性が生じることはわかっていますが、誰かがこのような変更を加えたのはこれが初めてではありません。 現在の動作にデフォルト設定されている「レガシー」フラグを追加し、警告（デフォルトの動作が変更されること）を追加し、後続のメジャーリリースでデフォルトを変更します。

さらに重要なことに、シリアライザーをDjangoの新しい事実上のものにしたい場合は、とにかくこの変更を行うことになります。 ModelFormから変換する人の数は、既存のユーザーベースを大幅に上回り、少なくともこの変更を期待します。

私の2セントを挿入する：
@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'}が含まれます。 2回目のPUTの後、 {'username': 'curly', 'role': 'admin'}になります。 これはべき等性を壊しませんか？ （私は完全にはわかりません-合法的に尋ねています）

編集：
PATCHのセマンティクスについては誰もが同じページにいると思います。

2番目のPUTの後に、{'username'： 'curly'、 'role'： 'admin'}があります。

私は、役割がデフォルトに戻ると個人的に驚きます（このreplaceオブジェクトの議論の理由はわかりますが、実際の問題はまだ発生していません）

私はまだそれで現実世界の問題を抱えたことはありません

ここでも同じですが、これまでのところ、私たちのプロジェクトはPATCHに依存しています:)
とは言うものの、並行性を処理するためのモデルバージョン管理を伴うOPのユースケースは私には理にかなっています。 PUTがデフォルト値（値が省略されている場合）を使用して、同時実行例外を発生させることを期待します。

まず、シリアライザーが必ずしもRESTfulRFCに従う必要がないことを認めることから始めましょう。 ただし、少なくとも互換性のあるモードを提供する必要があります。特に、RESTサポートを提供するパッケージではそうです。

私の最初の議論は第一原理からのものでしたが、 RFC （セクション4.3.4）は具体的に次のように述べています（強調を追加）：

POSTメソッドとPUTメソッドの基本的な違いは、囲まれた表現の意図が異なることで強調されています。 POSTリクエストのターゲットリソースは、リソース自体のセマンティクスに従って囲まれた表現を処理することを目的としていますが、PUTリクエストの囲まれた表現は、ターゲットリソースの状態を置き換えるものとして定義されています。
..。
特定のターゲットリソースでPUTを許可するオリジンサーバーは、ペイロードが部分的なコンテンツである可能性が高いため、Content-Rangeヘッダーフィールド（[RFC7233]のセクション4.2）を含むPUTリクエストに400（Bad Request）応答を送信する必要があります

したがって、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の動作をミラーリングするだけです）

_絶対的な_正解がないことは明らかですが、現在のところ、最も実用的な動作をしていると思います。

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は追加の情報をシリアライザーに渡す必要があります（$＃$ 1 $＃$の場合はおよそreplace=True PUT ）。 シリアライザーは、これを実装する方法を決定できます（すべてのフィールドを要求するか、デフォルトを挿入します）。

明らかに、これは大まかな提案にすぎませんが、デッドロックを打破する可能性があります。

さらに、PUT-as-createはそれ自体が有効な操作であるため、POSTとは異なる「必須」セマンティクスがあった場合も奇妙です。

PUTで作成できることに同意しますが、セマンティクスが同じであることに同意しません。 PUTは特定のリソースで機能します：

PUTメソッドは、ターゲットリソースの状態を作成するか、要求メッセージペイロードで囲まれた表現によって定義された状態に置き換えることを要求します。

したがって、作成のセマンティクスは実際には異なると思います。

• 役職to /citizen/は、SSN（社会保障番号）が生成されることを期待しています
• 置く/citizen/<SSN>にすると、特定のSSNのデータが更新されます。 そのSSNにデータがない場合は、作成されます。

「id」はPUTのURIに含まれている必要があるため、必要に応じて扱うことができます。 対照的に、POSTでは「id」はオプションです。

「id」はPUTのURIに含まれている必要があるため、必要に応じて扱うことができます。 対照的に、POSTでは「id」はオプションです。

それはそう。 「PUTに厳密に_all_フィールドを要求させる」という提案された変更は、PUT-as-createがPOST-as-createwrtとは異なる動作をすることを意味するという事実に特に言及していました。 フィールドが必要かどうか。

私は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 APIには役立ちません。実際には、フィクスチャのダンプとロードに限定されています。

あなたは私よりもDjangoとDRFの両方のアーキテクチャ上の仮定をよく知っているので、その方法についてはあなたに任せなければなりません。 確かに、 init kwargはそれに適切な感触を持っています...シリアライザーを「オンデマンド」で再構成します。 唯一の制限は、「オンザフライ」で再構成できないことですが、インスタンスは使い捨てであると想定しているため、これは重要な問題ではありません。

今のところ、これをマイルストーンから外します。 v3.7以降で再評価できます

皆さん次第ですが、これが同時実行サポートを追加するためのチケットではないことを明確にしたいと思います。 本当の問題は、単一のシリアライザーが現在のアーキテクチャでPUTとPOSTの両方を正しく検証できないことです。 並行性は「失敗したテスト」を提供しただけです。

TL; DRトムが提案した修正から始めると、この問題がブロックされる理由がわかります。

要約すると、提案された解決策は、 PUTリクエストに必要なすべてのフィールドを作成することです。 このアプローチには（少なくとも）2つの問題があります。

1. シリアライザーはHTTPメソッドではなくアクションで考えるため、1対1のマッピングはありません。 PUTとPOSTで共有されているため、明らかな例はcreate $です。 PUTによる作成はデフォルトで無効になっているため、提案された修正はおそらく何もないよりも優れていることに注意してください。
2. PUT （＃3648、＃4703で共有される感情）のすべてのフィールドを要求する必要はありません。 nillableフィールドが存在しない場合、Noneである可能性があります。 デフォルトのフィールドがない場合は、デフォルトを使用できることがわかります。 PUTには、実際にはPOSTと同じ（モデルから派生した）フィールド要件があります。

本当の問題は、欠測データと＃3648、＃4703の基本的な提案をどのように処理するかであり、ここでも正しい解決策を維持します。 if_missing_use_defaultのような概念を導入すれば、すべてのHTTPモード（create-by- PUTを含む）をサポートできます。 私の最初の提案では、 partialの代わりとして提示しましたが、直交する概念として考える方が簡単です（必要な場合もあります）。

if_missing_use_defaultのような概念を導入した場合。

これ、または厳密な「すべてのフィールドを必要とする」を基本シリアライザークラスとして実装し、それをサードパーティライブラリとしてラップすることを妨げるものは何もありません。

私の意見では、厳密な「すべてのフィールドを要求する」モードでもコアにすることができる可能性があります。これは非常に明確な動作であり、なぜそれが役立つのかがわかります。

「フィールドをオプションにすることはできますが、モデルのデフォルトが存在する場合はそれを使用して、すべてを置き換える」とは確信していません。これは、非常に直感に反する動作（たとえば、「created_at」フィールドが自動的に終了する）を示すようです。自分自身を更新する）。 より厳密な動作が必要な場合は、より厳密な動作を行う必要があります。

いずれにせよ、これに取り組む正しい方法は、サードパーティのパッケージとして検証してから、ドキュメントを更新してリンクできるようにすることです。

または、ユーザーが本当に必要とする動作がコアから欠落していると確信している場合は、プルリクエストを作成して動作とドキュメントを更新することを歓迎します。これにより、非常にメリットを評価できます。具体的な方法。

このための開始点としてプルリクエストを喜んで受け取ります。さらに、この動作を示すサードパーティのパッケージを含めることもできます。

PUT-is-strict動作のオプションを持つことで価値に近づきます。

これはまだ立っています。 誰かがそれらの線に沿ってプルリクエストを行うのに十分気にかけているなら、私たちはその側面をコアで考えることができると思います。 これはオプションの動作である必要があります。

これは、非常に直感に反する動作を示すようです（たとえば、「created_at」フィールドは、自動的に更新されます）。

created_atフィールドはread_onlyである必要があります（またはシリアライザーから除外されます）。 どちらの場合も、変更されません（通常のシリアライザーの動作）。 シリアライザーでフィールドが読み取り専用ではないという直感に反するケースでは、フィールドを自動的に変更するという直感に反する動作が発生します。

このための開始点としてプルリクエストを喜んで受け取ります。さらに、この動作を示すサードパーティのパッケージを含めることもできます。

絶対。 「デフォルトを使用」のバリエーションは、サードパーティパッケージの理想的なケースです。これは、変更が既存の動作（の1つの方法）の簡単なラッパーであり、（デフォルトの引数を購入した場合）すべての非部分的なシリアライザーで機能するためです。

tomchristieは4時間前に閉店しました

おそらく、「PR Welcome」や「サードパーティプラグイン」などのラベルを追加し、このような有効な/確認済みの問題を開いたままにしておくことを検討してください。 私はよく未解決の問題を検索して、問題がすでに報告されているかどうか、および問題の解決に向けた進捗状況を確認します。 クローズされた問題は「無効」または「修正済み」と認識しています。 いくつかの「有効だがクローズされた」問題を何千もの無効/修正された問題に混ぜても、効率的な検索はできません（それらが存在する可能性があることを知っていたとしても）。

おそらく、「PRWelcome」や「3rdPartyPlugin」のようなラベルを追加することを検討するでしょう。

それは十分に合理的ですが、プロジェクト自体のアクティブまたは実用的な作業を反映するように、課題追跡システムが必要です。

問題の範囲を厳しく保つことは、私たちにとって非常に重要です。 優先順位を変更すると、以前にクローズした問題を再開することを選択する場合があります。 今のところ、これは「コアチームは近い将来これに対処したい」から外れていると思います。

それが繰り返し発生し、サードパーティの解決策がない場合は、おそらくそれを再評価します。

このような有効な/確認済みの問題は未解決のままにしておきます。

問題管理スタイルに関するもう少しコンテキスト-https：//www.dabapps.com/blog/sustainable-open-source-management/