Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

DS.RESTAdapter can findMany in size-limited batches #531

wants to merge 2 commits into


None yet
9 participants

Especially in the case where hasMany associations have high-cardinality, sometimes the Ajax request to fetch many records at once will generate a URL that is longer than supported by the browser.

This pull-request adds a 'fetchBatchSize' property to DS.RESTAdapter that allows large collections to be fetched in fixed-size chunks. If left unset, the default behavior is essentially unchanged.


wagenet commented Jan 10, 2013

@seancribbs This seems pretty useful. Can you get it merging cleanly again?

@wagenet Will do.

seancribbs added some commits Dec 17, 2012

@seancribbs seancribbs Support fetching records in batches in DS.RESTAdapter.
This helps with high cardinality hasMany associations where the
generated URL may be longer than the browser supports.
@seancribbs seancribbs Accumulate Ajax requests across the batched findMany and verify all o…
…f them.

@wagenet Rebased, cleaned-up and force-pushed.


cmeiklejohn commented Jan 12, 2013

@wagenet thoughts on the rebased edition?


sly7-7 commented Jan 17, 2013

@seancribbs definitely usefull... I just encountered this type of problem... we were simulating the potential objects a user will manipulate. about 1000 items in one project... when entering /projects/42/items.... boom...
Perhaps there is an other workaround, but your PR seems fine. @wycats @tomdale @tchak any thoughts ?

Related to the old #241


darthdeus commented Feb 23, 2013


why do you not load the associated objects by their foreign key? this way you would have to pass only one id


bobbus commented Apr 23, 2013

@Goltergaul , I thought about this but there is no easy way to do it for now : when we access an hasMany relationship which was loaded by an array of ids, ember data automatically fire the requests to load all of them.


tomdale commented May 10, 2013

I'm going to opt to close this for now. We would like to encapsulate sparse array semantics than at a higher-level than the REST adapter.

@tomdale tomdale closed this May 10, 2013


tomdale commented May 10, 2013

We should continue the discussion on pagination in general on the JSON API spec.

@tomdale Maybe I misunderstand, but isn't this a transport-layer concern? The layers above should not care about how the requests are made to the backend, just that they are requesting an entire collection of records. The fact that browsers have a (sensible) limit on URL length seems to be something that is only the concern of the adapter.


tchak commented May 10, 2013

@tomdale I kinda agree with @seancribbs. It seems this and pagination are different concerns.

FWIW I'm not arguing for this particular pull-request, I realize it's out of date. I just think "sparse array semantics at a higher level than the REST adapter" fails to cover the problem it solves, unless you have something else in mind entirely.

@tomdale what do you mean by "sparse array semantics than at a higher-level than the REST adapter"?


wagenet commented Aug 10, 2013

#651 has been left open. Any further discussion should probably be there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment