Skip to content
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

included parameter potentially includes the object itself #524

Closed
hb9hnt opened this issue Dec 2, 2018 · 9 comments
Closed

included parameter potentially includes the object itself #524

hb9hnt opened this issue Dec 2, 2018 · 9 comments

Comments

@hb9hnt
Copy link
Contributor

hb9hnt commented Dec 2, 2018

Let's say we have a class Room and a class Person with a foreign key to Room. Now I want to create a new person in the room and reload all the people already in the room because adding the person might have changed them for some reason. Therefor I send a POST request containing the new person to

persons/?include=room.persons`

This lead to the newly created person to be included twice, once in the data property of the reply and once in the included property. Even though this isn't explicitly forbidden by jsonapi.org, Ember doesn't like this. IMHO an object shouldn't be included twice in a reply - meaning that this should be fixed on the DJA side of things.

@sliverc
Copy link
Member

sliverc commented Dec 3, 2018

I think this is a tricky issue as it might be that different frameworks have different expectations. Question is what the specification defines in the end to see where it needs to be fixed.

Specification of discussion would be on compound documents which sound a bit ambiguous on this issue.

This said do you have any other discussion links within the Ember or JSON API community where this issue has been discussed?

@hb9hnt
Copy link
Contributor Author

hb9hnt commented Dec 12, 2018

I didn't post this anywhere else. When I re-read the specification I thought it is pretty clear on this:

A compound document MUST NOT include more than one resource object for each type and id pair.

Note: In a single document, you can think of the type and id as a composite key that uniquely references resource objects in another part of the document.

Note: This approach ensures that a single canonical resource object is returned with each response, even when the same resource is referenced multiple times.

@sliverc
Copy link
Member

sliverc commented Dec 13, 2018

In a compound document, all included resources MUST be represented as an array of resource objects in a top-level included member.

Here the specification states that compound document is the top-level included member. This doesn't include the default resource object, so the statement that A compound document MUST NOT include more than one resource is as I understand it only relevant for the included member.

If it is understood this way how DJA implements it now would be OK.

I think in terms of payload fixing this would actually make sense, I am just not so sure on the clarity of the specification on this point, so it would be good to clarify it.

@hb9hnt
Copy link
Contributor Author

hb9hnt commented Dec 14, 2018

The crucial point is that it says in your quote in a compound document. It doesn't say that the included top level member is the compound document itself.

IMHO the specification is quite clear about what a compound document is:

To reduce the number of HTTP requests, servers MAY allow responses that include related resources along with the requested primary resources. Such responses are called “compound documents”.

i.e. the full response, including the data and the included top level member are part of the response called a compound document.

However, I will open an issue on the JSON API side later today.

@sliverc
Copy link
Member

sliverc commented Dec 14, 2018

I have overread this part, but with this in mind I agree that a resource object should not be added twice including primary data.

I guess it never can hurt to double check though with JSON API. Marking this as bug and a Pull Request is very welcome.

@hb9hnt
Copy link
Contributor Author

hb9hnt commented Dec 15, 2018

I didn't have the time to create the issue at JSON API. I'll leave it at that and look into fixing the problem. Would you happen to have some pointers for me to where to start looking to fix this?

@sliverc
Copy link
Member

sliverc commented Dec 17, 2018

The resource itself should be part of the included_cache so it will be skipped in the renderer if it gets included again.

See https://github.com/django-json-api/django-rest-framework-json-api/blob/master/rest_framework_json_api/renderers.py#L383

@hb9hnt
Copy link
Contributor Author

hb9hnt commented Jan 1, 2019

I'm almost ready to submit the PR. Before I do a couple of questions:

  • I wrote a integration test which tests this case but no unit test. Do we also need to unit-test this case?

  • Adding the resource itself to the included_cache is IMHO not the best approach as we then have to removed it again before building the included attribute of the response. Therefor I decided to just check in the end whether it is in the cache and remove it in this case. Could this lead to any problems I didn't yet fully grasp?

hb9hnt pushed a commit to hb9hnt/django-rest-framework-json-api that referenced this issue Jan 1, 2019
hb9hnt pushed a commit to hb9hnt/django-rest-framework-json-api that referenced this issue Jan 1, 2019
@hb9hnt
Copy link
Contributor Author

hb9hnt commented Jan 1, 2019

I just sent a PR for you to check out what I did. Feel free to reject the PR if it doesn't include everything I should have provided.

hb9hnt pushed a commit to hb9hnt/django-rest-framework-json-api that referenced this issue Jan 3, 2019
sliverc pushed a commit to hb9hnt/django-rest-framework-json-api that referenced this issue Jan 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants