-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 should be called instead of findMany if a has-many relationship is undefined #2162
Comments
+1— On Tue, Aug 5, 2014 at 10:04 PM, Tom Dale notifications@github.com
|
It may also be possible to eliminate the |
@tomdale those ID's get rather length especially if using guids. Which means we either need to treat them as POST's over GETS or have ember-data chunk the requests (lots of backends/api's may not support this easily). The last option seems to prefer findMany still existing, and having it call the url building multiple times for multiple discrete URL's |
@stefanpenner The recent "bucketing" feature by @igorT resolves this. Perhaps the URL-generator hook could support returning an array of URLs, which could be batched. |
@tomdale interesting, ya that makes sense. |
In fact #2159 |
+1 |
I am happy to help if someone has time to create a PR. |
@tomdale @igorT has this been resolved in 2.0+ ? I have a use case where the nested route produces aggregate level data, from a large dataset.
|
Having this would be super helpful for https://github.com/amiel/ember-data-url-templates, particularly to support the case @psteininger is talking about. Is anyone else working on this? and is it still desired by others? I'd be happy to give it a shot... |
I have submitted an RFC for this: emberjs/rfcs#266 |
With the refactor in #5410 it would be fairly trivial to call |
It's unfortunate we never fixed this; however, it's also now a moot point as the RequestManager gives users full control over fulfillment. emberjs/rfcs#860 |
Given a payload for a particular record, Ember Data currently resolves has-many relationships through the adapter using the following heuristic:
links
object, the store will call the adapter'sfindHasMany
hook.links
object, the store will call the adapter'sfindMany
hook, passing it the array of IDs provided in the payload after removing the IDs of any records that are already loaded.This behavior works well when the relationship is provided as a URL in the
links
object, or when the relationship is provided as an array of IDs.However, there is a third, very common case, where the relationship should be populated by fetching a URL, but the URL is derived from information contained in the record, rather than being provided in the payload, hypermedia-style.
For example, imagine the following model:
In this example, materializing the comments relationship by calling
post.get('comments')
should result in the client retrieving/post/123/comments
. Thus, the server sends the following payload for the post with ID 123:This case is extraordinarily common (I ran into it when writing an app that uses the Portland public transit API, and Django's REST framework uses this approach), but currently getting this to work requires synthesizing a fake
links
entry in the serializer'snormalizePayload
hook and filling it with garbage data, which is a huge PITA.@wycats and I think that it may be appropriate to add a third hook, which generates a URL for the relationship, and if that returns a value, the store will call
findHasMany
with the result. The currentlinks
behavior can be explained and implemented in terms of this new hook.The text was updated successfully, but these errors were encountered: