You can clone with
HTTPS or Subversion.
Expected behavior: lazily loading paginated data from a server is possible.
Actual: This doesn't appear to be the case without modifying Ember Data.
I spent some time fumbling around the other day trying to get lazy loading of hasMany relationships to work properly (specifically, I was trying to load paginated data from GitHub's API via JSONP), and it appeared to me to be impossible.
Per this answer on SO: http://stackoverflow.com/a/14532845/136839 it does not appear that what I'm trying to do is possible today without modifying the library.
pagination is a story that still needs to be addressed
I'd be really interested to see what comes out of this
Also looking for the answer to this--many of my hasMany child record are expensive to compute, so would like to only attempt to retrieve them when requested.
Incidentally, @stefanpenner: this isn't a paging issue, though the OP may have been trying to load paginated data. I'd be happy with loading all the child records, and even this isn't possible. See this stackoverflow question for more info.
@SphtKr thanks for the further clarification. Ya it looks like pagination is only part of the story.
I would love to spend time on this, but getting ember RC1 is the current major focus. Once ember 1.0 ships, I think a large amount of attention will go to ember-data. That being said, contributions would be awesome.
Anyways, to help move this along, if someone is wiling to throw up a jsfiddle or jsbin example, that would be a big help.
Here's a pull request (#672) that I believe addresses the issue.
Okay, a SO question I asked on this forever ago got an interesting response... I didn't realize it, but there's a test case for using findHasMany that has existed since at least December.
First, the test case seems to show that the intended/usual way to get to the findHasMany code path is for the backend to pass a URL string in the JSON property corresponding to the hasMany relationship, and then you can implement findHasMany to retrieve the data from the provided URL. Fundamentally, this seems to work!
Second, the implementation of findHasMany in the test case also seems to work, initially at least. As with every implementation of lazy-loading hasManys I've tried, I run into trouble if the parent record is reloaded/rematerialized from the server. But using a findHasMany implementation adapted from the test case and a small patch to DS.Model.hasManyDidChange, I can get lazy-loaded hasMany relationships marginally working. See my update on the SO question for the semi-working implementation.
Pagination is definitely on the roadmap for us. I'm going to close this issue for now, but rest assured we will be working on this soon!
Closing this issue makes some sense now, because it seems it's at least possible to load some data lazily (contrary to what I originally believed: that it was impossible to reach the code path that calls findHasMany). But again, pagination isn't really the issue here, it's lazy-loading of hasMany relationships. Is there another open issue that addresses this, that we could link to here?
I agree with @SphtKr. It has been possible to lazy load data for sometime now... however its the lazily loaded relationships that present a problem. When a toMany relationship is lazily loaded the code responsible for sync'ing the reverse relationships fails to work properly.