Extract type for each related instance #94
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of extracting the resource type for the whole related collection, extract the type for each instance individually. This way, polymorphic relationships (using something like django_polymorphic) are supported.
|
Could you provide us with a way to replicate your issue and test your solution uppon it? I don't see any problem about it but I would like to make sure. Also, what/how exactly does that address #77 ? |
|
It addresses this comment #77 (comment) I'll try to write a test. |
|
ha! okay I missed that comment - I have nothing against merging that... @jerel any objections ? |
|
Once we get the |
jerel
added a commit
that referenced
this pull request
Sep 17, 2015
Extract type for each related instance
|
Was that reverted ? |
|
I don't believe so:
|
martinmaillard
added a commit
to martinmaillard/django-rest-framework-json-api
that referenced
this pull request
Apr 21, 2016
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 pull request
Apr 21, 2016
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 pull request
Apr 21, 2016
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 pull request
Apr 29, 2016
jerel
added a commit
that referenced
this pull request
Apr 29, 2016
* 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 pull request
May 2, 2016
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of extracting the resource type for the whole related collection, extract the type for each instance individually. This way, polymorphic relationships (using something like django_polymorphic) are
supported.
This PR addresses an issue raised in #77
The next step will be to allow customizing the way the type is extracted for each instance, but I'm not sure how to go about that...