Let's assume I have a table on Slate with pagination enabled with a pageSize of 10 that is backed by an Object-Service-API query which has the following body format:
{
"objectSet": "objectSet.ObjectSet",
"objectSetContext": "optional<ObjectSetContext>",
"pageSize": "integer",
"pageToken": "optional<PageToken>",
"sort": "optional<list<PropertySort>>"
}
Let's also say I have 100 records total, when I first run the query, I start with "pageToken": null and the response gives the first 10 of the 100 records. The response also includes a pageToken set to something like: "v1.abc-some-uuid-xyz.10".
Now if I want to reach page 5 of the results which should show results 41 to 50, what do I pass as a pageToken to reach those results specifically?
In the case there is an existing valid page token from the first page query?
In the case no pageToken is currently set or it has already expired?
I couldn't find any documentation on the object-service-api. All I could find is in the Slate query tab.
There is a section in the internal documentation under /documentation/product/slate/writeback-foundry hinting at passing the pagination offset value as the page token. This means that it can be a changing integer value. No need to prefix by parsing the previous pagingToken. Example:
"{{w_tableWidget.gridOptions.pagingOptions.currentOffset}}"
For case 1:
In the case there is an existing valid page token from the first page
query?
you need to change the last number of the token v1.abc-some-uuid-xyz.10
-> this gives you the second 10 items ( 10 to 19).
you should reach the page with items no. 40 to 49 with this token v1.abc-some-uuid-xyz.40
I don't think case 2 is possible because the resulting object set will only be generated once you issue the query against Phonograph.
Related
I've been working with the drive SDK for the last few days and previously I was able to request 1000 items on a page using listrequest. Now I'm only getting 100 files no matter how high I set the parameter, but if I set it below 100 it will return whatever number. Did they decide to change the max results overnight or something?
I'm facing the same problem so I've been doing some tests and this is what I've found:
If I try files.list with fields: "files, nextPageToken", I get 100 files only.
If I try files.list with fields: "files(name, id, etc, parents), nextPageToken", I get 460 files.
If I try files.list with fields: "files(name, id, etc), nextPageToken" without parents field, I get 1000 files.
If I try files.list with fields: "files(parents), nextPageToken", I get 460 files.
So it seems that depends on how many fields you request and also if one of the fields requested is parents field.
You've misunderstood what pagesize does. It is a maximum value, not an absolute value. You should always iterate list results until nextPageToken is null.
Ok never mind I figured this out. I was requesting all the metadata of each file, which seems to limit the request to 100. I was able to get 1000 per page by requesting only three fields.
EDIT by pinoyyid: This is not the answer. There is nothing that you can do to guarantee that the page will have exactly pageSize items.
I wrote a Couchbase view and I'm querying this view from Python. Instead of the full set of data being returned, it is only returning the first 10 elements.
I don't want pagination, instead of pagination I want the entire set of data. Is there any way of doing this?
Below is my view code:
function (doc, meta) {
if (doc.type == "folder" && doc.location) {
emit(doc.location, meta.id);
}
}
And here is the Python code I wrote to run the query:
view_endpoint = "_design/restViews/_view/"+viewName+"?key=%22"+key
response = requests.get(view_url + view_endpoint).json()
return response
A Trusty source says:
When querying the view results, a number of parameters can be used to select, limit, order and otherwise control the execution of the view and the information that is returned. When a view is accessed without specifying any parameters, the view will produce results matching the following: Full view specification, i.e. all documents are potentially output according to the view definition.Limited to 10 items within the Admin Console, unlimited through the REST API.Reduce function used if defined in the view.Items sorted in ascending order (using UTF–8 comparison for strings, natural number order)
You can add parameters to the query before the view. One of them is:
limit: numeric Limit- the number of the returned documents to the specified number.
Good luck. :)
I'm trying to implement the JSON api (v2) of bigquery. In my code I get the same behaviour as on the documentation page for tabledata-list
My table size is about 11.000 rows. In the documentation page I fill in the following parameters:
ProjectId = X
DatasetId = Y
TableId = Z
MaxResults = 10000 #I want to paginate my results
This returns 10.000 rows and a pageToken. So I do the same request and now I set the page token so that I get the next page of results.
And that returns the same 10.000 rows as before. I expected this to do pagination as described on this page:
All collection.list methods return paginated results under certain circumstances. The number of results per page is controlled by the maxResults property
A page is a subset of the total number of rows. If your results are more than one page of data, the result data will have a nextPageToken property. To retrieve the next page of results, make another list call and include the token value as a URL parameter named pageToken.
Where do I go wrong?
EDIT:
My colleague pointed out to me that on the other documentation pages the result contains a nextPageToken except the response contains a pageToken. The difference being that where pageToken refers to the current page, the nextPageToken refers to the next page.
However the documentation states it should return a nextPageToken (except when there is no more data). But len(table) > len(result)
On the same page it's mentioned that there is a difference for TableData.List() call
The bigquery.tabledata.list method, which is used to page through
table data, uses a row offset value or a page token.
So for TableData.List() you must use the row offset value to paginate, and in order to access previous pages you can use your hashes from your session. This is built because with large volume and big data, you cannot pre-cache the next set of data from your worker pool.
You can help improving the documentation, by using the link on top right of each page that says: Feedback on this document feel free to use that to reach out with improvements.
Also you can submit issues to https://code.google.com/p/google-bigquery/issues/list
Unfortunately, the field returned for TableData.List() that contains the logical "next page token" is literally named "pageToken", rather than "nextPageToken".
Other APIs, like Datasets.List(), return a field literally named "nextPageToken" which contains the logical "next page token".
It's a case of inconsistent naming, but hopefully this helps clear up some confusion.
I'm using the drive change feed to find changes of files in Google Drive. I have been experiencing some inconsistency. I just tested using the API Explorer found here :
https://developers.google.com/drive/v2/reference/changes/list
On one user the largestChangeId returned was 1208, although when setting the startChangeId to 1208, the request returned 6 entries, including the change of 1208, and each other change being higher than 1208. I also have the flags includeDeleted = true, includeSubscribed = false.
I then tried on another user, the returned ID was 136023. When using this value with the same params as above Drive returned 0 entries, which I expected.
Then I tried on a third user, the returned ID was 8267. Then setting the call again with the same params as above Drive returned 1 entries, which had the same change id of 8267.
Note all three accounts are testing accounts on a test domain in which no documents are being modified or shared.
So three users three results making the same call. Is this expected or a better question, what should I expect when making this call. In the documentation it states : " Change ID to start listing changes from. (string)". When it says from and you are returned the highest ID I would expect 0 results to be returned.
Thanks.
I just wanted clarification with regard to the Files: list feature of the Google Drive API here:
https://developers.google.com/drive/v2/reference/files/list
What is the the maximum value that can be specified with maxResults? I assume this value calculates the number of results on the next page of results?
Also, is the nextPageToken simply part of the query string that's required to be passed with nextLink to get the next page of results?
Thanks!
The maxResults query parameter can be used to limit (or increase) the number of items returned in a list request. There is a default value and a hard limit that is set by our server.
Unfortunately, we don't usually document those numbers as they can easily change and recommend developers to look for a nextPageToken and/or nextLink in the resulting collection to know whether or not all items have been returned.
The nextPageToken attribute is to be used as the pageToken query parameter on a list request. If you are using the nextLink from the resulting collection, you do not need to specify the pageToken query parameter as it should already be included.
maxResults cannot be larger than 1000 according to this page: https://developers.google.com/drive/v2/reference/files/list