Could you do what you need using the $skip and $top parameters?
The $top and $skip querystring parameters, specified by OData, apply limit and offset operations to the data, respectively. The $count parameter, also an OData standard, will annotate the response data with the total row count, regardless of the scoping requested by $top and $skip. While paging is possible through these parameters, it will not greatly improve the performance of exporting data. ODK Central prefers to bulk-export all of its data at once if possible.
What do you need to do with a single record? Please describe your high-level need in as much detail as you can (what answers are you trying to get from the data, what existing systems do you need to integrate with, etc).
Downloading all data into one protected code repo / server and filtering locally works well for my use case, but I'm aware that my data is(threatened species in politically sensitive locations) is not on the same level of data privacy requirements and liability as human patient data.
Until ODK Central supports OData queries, the options are limited to the "download all data first" scenario.
In favour of this approach, at 1 PDF per patient I'd expect the combined report render time to outweigh the total download time (including earlier records), especially if media attachments are non existent or their download is skipped (ruODK::odata_submission_get(download=FALSE)).
@issa might have insight into performance for larger amounts of data. @dr_michaelmarks might be able to share real-world performance considerations with their famous 1 million+ Ebola records (Aggregate & encrypted forms & Briefcase).
We've discussed the ability to filter by submission metadata, particularly submission date and submitter ID. That sounds like it would help for pulling all patients last week. Do you have other filtering use cases as well?
One other thought: I'm not sure this is an official part of the API, but I think the ….svc/Submissions endpoint returns submissions in creation order (so that newer submissions come first). If you know you need the most recent submissions, you might be able to leverage that fact.
I also wanted to link to a few related discussions:
supporting strict equality filter in odata export is definitely not beyond consideration. the only issue is that we open the can of worms that is parsing odata filter expressions, and rejecting all the cases we can't handle (which will be most of them).
perhaps if our team grows we can entertain the idea of actually servicing a broad range of filter expressions. for now i think supporting strict equality filter over odata is a reasonable ask, but with our team as small as it is i'm not sure exactly when we will get to it. right now the focus is on web forms rather than on export.