Skip to content

ResourceRelatedField is too rigid for type validation #124

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.

Sign up for GitHub

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

Jump to bottom
Closed
jsenecal opened this issue Oct 9, 2015 · 2 comments
Closed

ResourceRelatedField is too rigid for type validation #124

jsenecal opened this issue Oct 9, 2015 · 2 comments
Labels
enhancement help wanted
Milestone
2.0 release

Comments

@jsenecal
Copy link
Member

jsenecal commented Oct 9, 2015

Opening this on behalf of @martinmaillard (#122 (comment))

ResourceRelatedField is way too rigid when it checks the valid type. It gets the expected type from the queryset, which means that:

  • it's not possible to customize the type of a relation (what is allowed by the resource_name on the serializer)
  • it's not possible to allow multiple types to be valid for one relation (useful with polymorphic relationships)
@jsenecal jsenecal added this to the 2.0 release milestone Oct 9, 2015
@jsenecal jsenecal added the bug label Oct 9, 2015
@jerel
Copy link
Member

jerel commented Oct 22, 2015

Related to this we can now specify the type manually by passing model=FooModel to the ResourceRelatedField. https://github.com/django-json-api/django-rest-framework-json-api/blob/develop/example/serializers.py#L29-L30

This does not solve the multiple types feature request.

martinmaillard added a commit to martinmaillard/django-rest-framework-json-api that referenced this issue Apr 21, 2016
@martinmaillard
Add failing test for resource name consistency
b6e2624 
When setting `resource_name = None`, the related instance's resource
name is used in `relationships`, but `None` is used in `included`.

This is related to
django-json-api#94
and django-json-api#124
martinmaillard added a commit to martinmaillard/django-rest-framework-json-api that referenced this issue Apr 21, 2016
@martinmaillard
Add failing test for resource name consistency
c88a1f8 
When setting `resource_name = None`, the related instance's resource
name is used in `relationships`, but `None` is used in `included`.

This is related to django-json-api#94 and django-json-api#124
@martinmaillard martinmaillard mentioned this issue Apr 21, 2016
Merged
martinmaillard added a commit to martinmaillard/django-rest-framework-json-api that referenced this issue Apr 21, 2016
@martinmaillard
Fix included resource type inconsistency
f1b0691 
When setting `resource_name = None`, the related instance's resource
name is used in `relationships`, but `None` is used in `included`.

This is related to django-json-api#94 and django-json-api#124
jerel pushed a commit that referenced this issue Apr 29, 2016
@martinmaillard @jerel
Fix included resource type inconsistency (#229)
2bd4aea 
When setting `resource_name = None`, the related instance's resource
name is used in `relationships`, but `None` is used in `included`.

This is related to #94 and #124
jerel added a commit that referenced this issue Apr 29, 2016
@jerel
v2.0.0-beta.2 -> v2.0.0
b9ccd9d 
* docs: note about importing serializers

* Document ResourceRelatedField and RelationshipView

* Updated pip install instructions for 2.0.0-beta.2

* Add LimitOffsetPagination

* Dont let the offset go into negative space

* Add basic unit test for LimitOffsetPagination

* Support deeply nested includes
Allow skipping of intermediate included models

* Add current tox.ini directory to PYTHONPATH in order to use imports form there
Fix regression on PY3 caused by unicode_literals

* [FEATURE]: support using get_serializer_class on view

* fixed extract_root_meta for lists

* Fixed get_resource_name in case of non-model backed serializer.

Closes #219

* ResourceRelatedField now accepts serializer methods when many=True

* Rename "suggested" posts to "featured" so we can use suggested as many=True

* Updated SerializerMethodResourceRelatedField to allow many=True

Issue #151
Closes #220

* Correct error responses for projects with different DRF-configurations (#222)

* [#214] Add error messages tests.

* [#214] Extract formatting DRF errors.

* Add example view with custom handle_exception.

* Use HTTP 422 for validation error responses.

* Add full example of class-configured json api view.

* Fixed naming that suggested settings were used to inflect relationship names.

JSON_API_FORMAT_RELATION_NAME actually inflected the `type` instead.
The relation name is not changable at this time although if it woudl
be useful to someone it would be fine to implement it.
Closes #136.

* Updated changelog

* Added a doc note to prefer setting resource_name on serializers or models.

Closes #207

* Added get_related_field_name method to RelationshipView

* Added get_related_field_name method to RelationshipView

* Added docs about field_name_mapping

* Updated the readme for testing (#234)

* Allow exception handler to be used by normal DRF views: (#233)

* Add top-level 'errors' object to non-JSON-API responses
* Allow configuring the exception handler to be used _only_
  in JSON API views or uniformly across all views

* Fix included resource type inconsistency (#229)

When setting `resource_name = None`, the related instance's resource
name is used in `relationships`, but `None` is used in `included`.

This is related to #94 and #124

* Fixes #230. Keep write only fields from having an attribute key

* Release v2.0.0

* Update setup.py to classify as production/stable
khornberg pushed a commit to imtapps-dev/django-rest-framework-json-api that referenced this issue May 2, 2016
@martinmaillard @khornberg
Fix included resource type inconsistency (django-json-api#229)
f15e9a4 
When setting `resource_name = None`, the related instance's resource
name is used in `relationships`, but `None` is used in `included`.

This is related to django-json-api#94 and django-json-api#124
@sliverc
Copy link
Member

sliverc commented May 2, 2018

With #306 and introduction of polymorphic models support I think this issue has been addressed.

Therefore closing. If you see an area of this issue which has not been addresses please comment.

@sliverc sliverc closed this as completed May 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement help wanted
Projects
None yet
Milestone
2.0 release
Development

No branches or pull requests
3 participants
@jerel @sliverc @jsenecal