Pagination #113
Pagination #113
Conversation
ghost
mentioned this pull request
|
This should probably use that. |
|
So I was initially going to try that, but I was wary of not returning some sort of "total" in the pagination data, which as far as I can tell isn't provided by the streamsql calls. I could also add a manual sql query to each of the getAll functions that just gets a total row count, but I wasn't sure if that was reaching a threshold of ugliness that made it all not worth it. |
| @@ -13,7 +13,7 @@ | |||
| "dependencies": { | |||
| "mysql": "~2.0.0-alpha9", | |||
| "restify": "~2.6.1", | |||
| "streamsql": "~0.8.0", | |||
| "streamsql": "git+https://github.com/brianloveswords/streamsql.git#count-with-pagination", | |||
There was a problem hiding this comment.
Need to wait on merging this until this is a proper version. Just using the branch for now for testing purposes.
|
Alright, this is now using streamsql's phat pagination. Also added tests to each route that can be paginated. |
|
Updated package.json to use streamsql's new 0.8.3 version that supports pagination (not strictly necessary as it would fall under ~0.8.0 anyway, but hey). |
|
This is now broken from merging those other PRs, needs rebasing |
|
Word. |
|
Alrighty, 'tis rebased. |
| @@ -0,0 +1,11 @@ | |||
| module.exports = function sendPaginated(req, res, responseData, total) { | |||
| if (req.pageData) { | |||
| responseData._pageData = { | |||
There was a problem hiding this comment.
Any particular reason for naming the property _pageData? The preceding underscore suggests that it's private, but presumably the consumer would want to use this data, right?
There was a problem hiding this comment.
Heh, yeah, this is one of those things that looked more wrong to me the more I worked with it, so I'm happy to change it. My original thought was to do this to avoid conflicting with a "real" data element that happened to be named pageData, since I wasn't too keen on changing the entire structure of our responses by tucking all of our current results inside a "results" field or something. That said, this is obviously a largely theoretical concern, since the likelihood of our responses needing a field called pageData that isn't related to pagination is probably not too high. I'll change these, it's gross.
|
looks good to me. |
|
I'm adding this pagination info to the docs on the relevant routes:
Hope that sounds right..! |
|
That is indeed correct! Thank you, sue. |
|
great thanks @christensenep 😬 |
This adds pagination support for all non-singleton GET routes.
This is very basic pagination that simply allows the API consumer to specify a page and count in the querystring in order to limit the results. There is no snapshotting of data, so if deletions or additions occur between calls, the pages may have redundant or insufficient data. Each call to a paginated function also returns a _pageData object in the body, which contains the current page, count per page, and the total number of objects available.
Note that there is no pagination going on yet at a deeper level than simply filtering the results returned (the database is still being queried for the full result set).