As a developer and command line user of https://purl.bdrc.io queries, I find the default page size that limits the return to be an obstacle. The default page size allows for nice scrolling of the returned data in a browser, which is something we never do operationally. AOs use of queries is from a script or from the command line. We process the return set all in one unit of work. It is a difficulty to always have to include it in our queries, and page through the results.
Most of the time, the query results are small, such as the list of image groups in a work, or the count of images in an image group. But when they are large, the system 500s when the caller tries to put in an arbitrarily large number. As well, these queries are infrequent, no more than 4 or 5 per average day (iusuallly when building manifests)
I could accept having to add a value to the HTTP request header to the effect of "give me everything, unpaged."
As a developer and command line user of
https://purl.bdrc.ioqueries, I find the default page size that limits the return to be an obstacle. The default page size allows for nice scrolling of the returned data in a browser, which is something we never do operationally. AOs use of queries is from a script or from the command line. We process the return set all in one unit of work. It is a difficulty to always have to include it in our queries, and page through the results.Most of the time, the query results are small, such as the list of image groups in a work, or the count of images in an image group. But when they are large, the system 500s when the caller tries to put in an arbitrarily large number. As well, these queries are infrequent, no more than 4 or 5 per average day (iusuallly when building manifests)
I could accept having to add a value to the HTTP request header to the effect of "give me everything, unpaged."