What’s a good pattern for dealing with a large number of models on the other side of a hasMany relationship? For example, if I have a hasMany that would resolve into 1 million models and I’m using the RESTAdapter/RESTSerializer, it seems like a bad idea to just hand back all 1 million ids as a field in the main belongsTo model.
So what should I do instead? I’m scratching my head on this one.
I suspect you wouldn’t want to model the relationship and handle loading the relations manually with pagination. Could be wrong though 
Probably not. I’m aiming more for a solution where the paging is in the route. The user is investigating the results of a batch process so they’d hit a url similar to /myapp/batch/someBatchId/1. This would show them summary data about the batch as well as the first page of data (likely side loaded in the response for the batch summary data).
I was reading that this is what the links response is for, so I might try that.
SailsJs + these blueprints gets you links quick if you want to spike some code:
I’d like to resurrect this post. I’m also interested in how to deal with large relationships in ember-data.
I feel that as part of the “ambitious web apps” mantra, there should be some sort of recommended technique for dealing with this problem.
An ideal technique would allow developers to model a large hasMany relationship (1000+ related records) with ember-data without having to pass a long list of ids with the parent record. Additionally, when it is time to load related records, a recommended technique should exist for requesting filtered, paginated, or sorted records from the server.
Is the links response the solution for this problem? If so, does anyone know of a tutorial/blog post that they could direct me to? I’m especially interested in how to paginate/filter/sort the large hasMany records server-side.
Thanks!
In our projects, for cases like this we do not resolve the relationship via Ember-Data, but (as mentioned as a possible solution above), simply query the API accordingly.
So instead of doing: item.get('subitems'), we do this.get('store').query('subitems', { item: item.get('id') }, which then allows us to filter, sort, paginate etc. as we want.
If we want to filter/sort/paginate a set of items, I don’t really see the advantage of using an automatically resolving relationship - If I resolve a relationship, I’d expect to get all records.
If I resolve a relationship, I’d expect to get all records.
I think this is the fundamental insight. It took me a long time to wrap my head around this since so many of the beginning tutorials are eager to show off the automatic relationships, but for large relationships I use an “old fashioned” query and a route + controller using queryParams.
Thank you both so much for your input!
I can’t believe I didn’t think of that, but this.get('store').query('children', { parent_id: parent.get('id') } would totally work.
Does this mean you typically avoid parent.get('children') in your code (since this would resolve the relationship)? As a workaround, do you regularly employ the ds-references ember-data API to fetch already-loaded relationship records without resolving the entire relationship?
Thanks again!
It depends. Generally, for hasmany relationships with a huge amount of data (e.g. 1 parent → hundreds of children), I only specify the belongsTo relationship on the child but not the hasMany one on the parent. Whenever I need to load the children, I query them manually anyhow. This has worked quite well for me so far.