I moved three files in My Drive to the trash. Then retrieved changes with Changes: list API (https://developers.google.com/drive/v2/reference/changes/list). It returned three changes, with ids 11607, 11608 and 11609. However, the largestChangeId field was 11608. When I made the API request again with startChangeId: 11608, it returned the two last changes. When I made the API request with startChangeId: 11609, it returned no result.
Is it expected? Or relying on change ids in such a way is not right?
In your case, it looks like you're exposed to a bug. I'm adding details of the changes list and how it should work in normal circumstances. Let's assume your latest change id was 11606 and you made three trashing operations.
GET changes?startChangeId=11607 should list:
11607
11608
11609
And the next time you are requesting changes.list, you should always increment the latest latestChangeId by 1.
In this case you need to request the following on your next poll.
GET changes?startChangeID=11610 and it will be returning an empty list.
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'm trying to scrape the price from the first ticket here page using this xpath:
'.//*[#class="price"]/text()'
This works in the developer's console, but not when I run it in the scrapy shell using response.xpath. I have also tried to following in the shell:
'.//*[#class="initial"]/div[#class="price"]/text()'
and
'//*[#id="tVB901769989"]/div[1]/div[4]' (although I don't think that the id property can be used in the shell like this).
Is there something wrong with the xpaths that I've used, or is there some thing different with the way the page works? Any help would be appreciated. Thanks!
this happens because you are checking at different requests, the page you see doesn't have the information you need inside that file, but it gets it dynamically, in this case from: www.vividseats.com/javascript/tickets.shtml?productionId=1771684
There you can check the prices on json format, I think this is for one item:
{
"s":"Section 111",
"r":"8-22",
"q":"4",
"p":"692.00",
"i":"VB782041491",
"d":"111",
"n":"Zone Seating. The seller is committing to procure these tickets for you upon receipt of your order. After you place your order and your order is confirmed, we guarantee that your tickets will be within the listed zone
or section listed or one comparable and that you will receive these tickets in time for the event or
your money back. Orders exceeding four tickets may be split up into different rows within the requested
zone or section.",
"f":"0",
"l":"Section 111",
"g":"0",
"e":"0",
"h":"07/21/15",
"t":"0",
"v":"",
"c":"84352",
"z":"1",
"rhdn":"0",
"ind":"0",
"sd":"0"
}
where p contains the price.
I'm using Gerrit REST API to query all changes whose status is "merged". My query is
https://android-review.googlesource.com/changes/?q=status:merged&n=2
where "n=2" limits the size of query results to 2. So I got a JSON object like:
Of course there are more results. According to the REST document:
If the n query parameter is supplied and additional changes exist that match the query beyond the end, the last change object has a _more_changes: true JSON field set. Callers can resume a query with the N query parameter, supplying the last change’s _sortkey field as the value.
So I add the query parameter N with the _sortkey of the last change 100309. The new query is:
https://android-review.googlesource.com/changes/?q=status:merged&n=2&N=002e4203000187d5
With this new query, I was hoping that I'll get another 2 new query results, since I provided the _sortkey as a cursor of my previous search results.
However, it's really weird that this new query returns exactly the same results as the previous query, instead of the next 2 results as I expected. It seems like providing "N=002e4203000187d5" has no effect at all.
Does anybody know why using _sortkey to resume my query doesn't work?
I chatted with one of the developers at Google, and he confirmed that _sortkey has been removed from the newer versions of Gerrit they are running at android-review and gerrit-review. The N= parameter is no longer valid. The documentation will be updated to reflect this.
The alternative is to use &S=x to skip x results, which I tested and works well.
sortkey is deprecated in Gerrit v2.9 -
see the (Gerrit) ReleaseNotes-2.9.txt, under REST API - Changes:
[[sortkey-deprecation]]
Results returned by the [query changes] endpoint are now paginated using offsets instead of sortkeys.
The sortkey and sortkey_prev parameters on the endpoint are deprecated.
The results are now paginated using the --limit (-n) option to limit the number of results, and the -S option to set the start point.
Queries with sortkeys are still supported against old index versions, to enable online reindexing while clients have an older JS version.
See also here -
PSA: Removing the "sortkey" field from the gerrit-on-borg query interface:
...
Our solution is to kill the sortkey field and its related search operators (sortkey_before, sortkey_after, and resume_sortkey).
There are two ways you can achieve similar functionality.
Add "&S=" to your query to skip a fixed number of results.
(Note that this redoes the search so new results may have jumped ahead and
you might process the same change twice.
This is true of the resume_sortkey implementation as well,
so your code should already be able to handle this.)
Use the before/after operators.
Instead of taking the sortkey field from the last returned change and
using it in a resume_sortkey operator, you take the updated field from
the last returned change and use it in a before operator.
(This has slightly different semantics than the sortkey field, which
uses the change number as a tiebreaker when changes have similar updated times.)
...
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.
Using the Box 1.0 REST API, I am trying to work with the functions in SOAP UI.
The API doc for get_managed_users with user_id=12345 (internal id retrieved with get_user_id call correctly) is returning all the users. The docs say that would be the case if you do not specify a user_id value. But my full command is: (Token and API key changed to protect the clueless)
https://www.box.com/api/1.0/rest?user_id=27360&auth_token=blahbalhblah1234&action=get_managed_users&api_key=someKeyYouShouldNotSee
Now I could work with the complete result list, but that won't scale as we get thousands of users into the system.
I can make a call with edit_managed_user, using the same user_id value and the change is reflected in the UI, and in the next get_managed_users call. Thus I do have the correct user_id value, I would so assume.
I tried testuser#gmail.com as the user_id value as well, and get the entire list back. This leads me to believe that somehow I am sending user_id wrong, but I just do not see it.
Any hints? Why, with what seems like a valid user_id value is it acting like it is absent or incorrect?
Most likely you have either called this method with an invalid user_id, or one that is not in your set of managed users. Can you double check that the user comes back in your list of already managed users?