findHasMany should be called instead of findMany if a has-many relationship is undefined

[tomdale]

Given a payload for a particular record, Ember Data currently resolves has-many relationships through the adapter using the following heuristic:

1. If the relationship is defined in the top-level links object, the store will call the adapter's findHasMany hook.
2. If the relationship is not defined in the top-level links object, the store will call the adapter's findMany 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:

// models/post.js
var attr = DS.attr,
    hasMany = DS.hasMany;
export default DS.Model.extend({
  title: attr(),
  body: attr(),
  comments: hasMany()
});

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:

{
  "id": 123,
  "title": "Rails is Omakase",
  "body": "Trololol"
  // Note lack of comments relationship
}

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's normalizePayload 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 current links behavior can be explained and implemented in terms of this new hook.

[recipher]

+1— Johnny H 07971 880871

On Tue, Aug 5, 2014 at 10:04 PM, Tom Dale notifications@github.com wrote:

Given a payload for a particular record, Ember Data currently resolves has-many relationships through the adapter using the following heuristic:

1. If the relationship is defined in the top-level links object, the store will call the adapter's findHasMany hook.
2. If the relationship is not defined in the top-level links object, the store will call the adapter's findMany 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:

// models/post.js
var attr = DS.attr,
    hasMany = DS.hasMany;
export default DS.Model.extend({
  title: attr(),
  body: attr(),
  comments: hasMany()
});

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:

{
  "title": "Rails is Omakase",
  "body": "Trololol"
  // Note lack of comments relationship
}

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's normalizePayload 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 current links behavior can be explained and implemented in terms of this new hook.

Reply to this email directly or view it on GitHub: https://github.com/emberjs/data/issues/2162

[tomdale]

It may also be possible to eliminate the findMany hook, by calling the URL-generator hook with the IDs and having it create the appropriate URL that is passed to findHasMany.

[stefanpenner]

@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

[tomdale]

@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.

[stefanpenner]

@tomdale interesting, ya that makes sense.

[igorT]

In fact https://github.com/emberjs/data/pull/2159

[thomasdashney]

+1

[igorT]

I am happy to help if someone has time to create a PR.

[psteininger]

@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. Let's say I have widgets, and each widget has thousands of scores, but they are only exposed as aggregates, w/o id property. A URL looks like so:

/widgets/:id/scores_by_month 

[amiel]

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...

[amiel]

I have submitted an RFC for this: https://github.com/emberjs/rfcs/pull/266

[runspired]

With the refactor in #5410 it would be fairly trivial to call findHasMany instead of findMany in this particular case.

[runspired]

It's unfortunate we never fixed this; however, it's also now a moot point as the RequestManager gives users full control over fulfillment. https://github.com/emberjs/rfcs/pull/860