Skip to content

ResourceRelatedField: Support resource_name in to_internal_value #302

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
czosel opened this issue Nov 29, 2016 · 1 comment
Closed

ResourceRelatedField: Support resource_name in to_internal_value #302

czosel opened this issue Nov 29, 2016 · 1 comment

Comments

@czosel
Copy link
Contributor

czosel commented Nov 29, 2016

I'm trying to modify the type of a ResourceRelatedField: Instead of the model name, i'd like to serve another name.

For GET requests, that works nicely because to_representation considers resource_name on the serializer (if the field is part of included_serializers).

However, POSTing a new resource under the different resource_name does not work, because to_internal_value considers only the model for expected_relation_type.

Suggestion: Allow passing resource_name to ResourceRelatedField. If specified, it

  • is used in to_internal_value to map to the actual resource name (which is read from the queryset)
  • should take priority over resource_name on the serializer in to_representation

What do you think? Is there an easier approach to this? I'd be happy to provide a PR if you think this is the way to go.

PS: In case you wonder, our use case for this: We need two different endpoints with different permissions and serializers for the same underlying Django model. (The "owner" of the model sees more than anyone else.)

@czosel
Copy link
Contributor Author

czosel commented Dec 2, 2016

After giving this some more thought, i noticed that it would make much more sense if to_internal_value works the same way as to_representation: By checking Meta.resource_name on the corresponding serializer. So thats how i implemented it in #306.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant