mbroadst
commented
9 years ago The pagination options were designed to be defined on a resource level, but you're correct that you might want to control that more finely for what I've termed subresources (children/unicorns/whatever you want to call them). These are the resources automatically generated, and associated with a top level resource.
Currently these are accessible as top level properties of the resource you're working with (maybe not the best decision since there could potentially be overlap with existing properties?). So, given the previously discussed album/songs configuration, you would set those options via albumResource.songs.<options>. As far as solving the bug itself, I think the real issue is that not all relevant configuration data is being passed down to the children of the parent resource during construction (here is an example).
If you were going to put a PR together, I would start there and tests related to ensuring that behavior would be very much appreciated :)
pagination has got mixed up, it's always true once we get to List.prototype.fetch
Ah, further investigation shows that we are calling Resource on these related models, and it's flipping pagination back to the default of true for them. As everything is related to something, it always gets Resource called on it second hand and pagination turned back on. I dont need pagination, though I will, though may be > 1000. but for now I can nail it off but I will try and see where we are supposed to be passing that option on, Fixing this is likely to break stuff I am sure, so please dont fret, I'll submit a pull req in a bit if I can work out where we should be forwarding the pagination flag, and a variable for the 1000 max, but you might want a parent to be un-paginated and the child paginated, so care needed.