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

FindHasMany calls buildURL using the parent type/id #2564

Closed
igorT opened this issue Dec 8, 2014 · 6 comments
Closed

FindHasMany calls buildURL using the parent type/id #2564

igorT opened this issue Dec 8, 2014 · 6 comments

Comments

@igorT
Copy link
Member

igorT commented Dec 8, 2014

It's a bug that we do that here
https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/rest_adapter.js#L410

@karanjthakkar
Copy link
Contributor

@igorT The url in description is broken. Any update on how to proceed with this?

@bmac
Copy link
Member

bmac commented Jun 12, 2015

@karanjthakkar I believe this is an updated link:

url = this.urlPrefix(url, this.buildURL(type, id, null, 'findHasMany'));

@Serabe
Copy link
Member

Serabe commented Jul 20, 2015

I might have time to dig into this. Is it still without contributor?

@Serabe
Copy link
Member

Serabe commented Jul 21, 2015

Digging into this issue, I see that the constructed URLs for hasMany and belongsTo relationship are indistinguishable from the one to get the parent type.

In build-url-mixin, urlForFindHasMany and urlForFindBelongsTo only receive an id and a modelName; there is no relationship information available. As of JSONAPI specification, the suggested relationship URL with the related data looks like /parentType/id/relationshipName: there are at least one

On the other hand, the adapter.buildURL = function() {...} in some test leaks to the rest of the tests.

@runspired
Copy link
Contributor

@wecc this should be combined with whatever other issues we have around fixing hasMany relationships to always hit findHasMany and urlForHasMany

@wecc
Copy link
Contributor

wecc commented Oct 22, 2016

Yeah, I'm closing this in favor of #2162.

@wecc wecc closed this as completed Oct 22, 2016
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

6 participants