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

Bug: Retrieving a relationship where the items are located in the "data" collection instead of the "included" collection #155

Open
HendrikN opened this issue Sep 5, 2018 · 5 comments

Comments

@HendrikN
Copy link

HendrikN commented Sep 5, 2018

What's the problem
Retrieving a relationship where the items are located in the primary "data" collection instead of the "included" collection won't return anything.

Steps to reproduce
For example: The JSON-API returns a collection of students and the studentGroups the students are assigned to. The studentGroups are available in the included segment of the response. The data segment contains all the students. There's a hasOne relationship from a student to a studentGroup, and a hasMany from a studentGroup to the containing students. The JSON:

{
	"data": [{
			"type": "student",
			"id": "1",
			"attributes": {
				"name": "Rick"
			},
			"relationships": {
				"student_group": {
					"data": {
						"type": "student_group",
						"id": "1"
					}
				}
			}
		},
		{
			"type": "student",
			"id": "2",
			"attributes": {
				"name": "Morty"
			},
			"relationships": {
				"student_group": {
					"data": {
						"type": "student_group",
						"id": "1"
					}
				}
			}
		},
		{
			"type": "student",
			"id": "2",
			"attributes": {
				"name": "Jerry"
			},
			"relationships": {
				"student_group": {
					"data": {
						"type": "student_group",
						"id": "2"
					}
				}
			}
		}
	],
	"included": [{
			"type": "student_group",
			"id": "1",
			"attributes": {
				"description": "Awesome people",
				"active": true
			},
			"relationships": {
				"students": {
					"data": [{
						"type": "student",
						"id": "1"
					}, {
						"type": "student",
						"id": "2"
					}]
				}
			}
		},
		{
			"type": "student_group",
			"id": "2",
			"attributes": {
				"description": "Annoying people",
				"active": true
			},
			"relationships": {
				"students": {
					"data": [{
						"type": "student",
						"id": "3"
					}]
				}
			}
		}
	]
}

When I try to retrieve all the students in a studentGroup, it will return an empty collection, since the students are not in the included-segment of the response. The JSON API specification says about this:

Compound documents require “full linkage”, meaning that every included resource MUST be identified by at least one resource identifier object in the same document. These resource identifier objects could either be primary data or represent resource linkage contained within primary or included resources.

Just adding the students to the included-segment as well, would be a violation of the spec (also, devour will enter an infinite loop when I do):

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

See: http://jsonapi.org/format/#document-compound-documents

How could this be fixed
It looks like the code only takes the items in included in to account when parsing relationships. This should be concatted with the items in the primary data as well.

@Auspicus
Copy link
Collaborator

@HendrikN Do you think: #153 will bring us to spec compliance here?

@JaZo
Copy link
Contributor

JaZo commented Jul 12, 2019

@Auspicus, it is related, but not completely the same. That PR is a starting point to have (in this example) the ids of the students. But for this issue the whole student objects need to be present on the student_group->student relation, not only the ids.

@Auspicus
Copy link
Collaborator

@JaZo AFAIK that feature already exists when making a request and adding included relationships.

@JaZo
Copy link
Contributor

JaZo commented Jul 15, 2019

Indeed, but this issue is about relations from included items to items in the "main" data.

@gadelkareem
Copy link

Any updates on this?

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

4 participants