Do not treat missing non-form data as empty dict #7199
Conversation
| @@ -103,6 +103,13 @@ A view inspector class that will be used for schema generation. | |||
|
|
|||
| Default: `'rest_framework.schemas.openapi.AutoSchema'` | |||
|
|
|||
| #### DEFAULT_MISSING_DATA | |||
There was a problem hiding this comment.
Maybe let's call this something like EMPTY_REQUEST_DATA?
The DEFAULT_XYZ cases make sense because they're things that can be overridden, and are populating the default value. In this case it's not a default case that can be overridden, but rather the base case that it always used if there's an empty request.
There was a problem hiding this comment.
Happy to take feedback on alternate naming choices, too.
There was a problem hiding this comment.
I chose "missing" as opposed to "empty" because conventional usage of the word "empty" would suggest that a request body of "", [] or {} is also empty (len(request.data) == 0 after deserialization). I feared that if we call it "EMPTY_DATA", one may think that any "empty-like" payload would be coerced into this value. -- However, I don't feel strongly, as long as the documentation is clear.
Regarding whether it is a default: If by "override", you mean overriding by view attribute or similar, fair enough; one could also argue that the client can override it (by sending data), which would warrant the name DEFAULT_DATA or DEFAULT_REQUEST_DATA.
(Also, it's conceivable that there would a view attribute to override this setting at some point, although right now the request would not have the corresponding context.)
Having said all this, I think my favorite would be DEFAULT_REQUEST_DATA, as I think it is accurate and future-proof. But in the end, I don't have any stakes in the naming, and will be ok with whatever you prefer.
|
@tomchristie Do you need anything else from me to take the next step with this? |
This allows views to distinguish missing payload from empty payload. Related: encode#3647, encode#4566
peterthomassen
force-pushed
the
proper_empty_payload
branch
from
c26eb31 to
8b52dc0
Compare
|
@tomchristie I rebased this PR on top the the current master and resolved conflicts. Is there anything else I can do to help with this PR? |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I think this is still current. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I think this is still current. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I think this is still current. |
|
@auvipy Do you think this can be revived? |
|
will come back to this next sun/monday |
|
I'm not convinced that adding new API surface area to REST framework is a net positive. |
| @@ -341,7 +341,7 @@ def _parse(self): | |||
| if media_type and is_form_media_type(media_type): | |||
| empty_data = QueryDict('', encoding=self._request._encoding) | |||
| else: | |||
| empty_data = {} | |||
| empty_data = api_settings.DEFAULT_MISSING_DATA | |||
There was a problem hiding this comment.
instead of exposing a new API can we just handle the empty data as None value instead of dict?
There was a problem hiding this comment.
That was my initial proposal, and I have no objection to doing so. However, please see the discussion in #7195 (comment) (and the context that led up to this post).
There was a problem hiding this comment.
what I am suggesting you is based on this comment #7199 (comment) as Tom is reluctant to introduce new API surface to the framework. I saw those discussions as well and do agree with most of them.
There was a problem hiding this comment.
Yes, but Tom was even more reluctant to silently change the behavior ("too big of a behavior change" in this earlier comment). He seemed to be more ok with adding the setting, see #7195 (comment).
I have no stakes, and either way is fine for me. It's just think that this question needs clarification between Tom and you, and I can't answer it.
There was a problem hiding this comment.
@tomchristie need your input here
This allows views to distinguish missing payload from empty payload.
Related: #3647, #4566
Description
continuation of #7195