I am integrating with the v2 Box rest api from an iOS app.
When I upload a file I cache it's modified date (as reported by Box in the return JSON)
Sometime later, I request the folder contents and check the modified date on the file (to see if it's changed since I last uploaded.) Depending upon how long I wait, the modified date changes - wtf!!!
If I request the folder contents immediately (msecs) after upload then the modified date is as it was after upload. If I wait 3 or 4 seconds then the date changes (by 1 second typically.)
Anyone from Box know why this might be - and how to fix it?
I don't know the answer to your particular question, but this caught my eye:
I ... check the modified date on the file (to see if it's changed since I last uploaded.)
If you're primarily concerned with detecting changes, then you might instead consider using the etag or version properties of the file object. They are designed for exactly this purpose.
Related
I'm considering using Google Drive push notification in order to replace our currently pulling process.
I started playing with it, but I have 2 major problems:
Watching changes:
When watching for drive changes, I get notification with the new change id. But when I try to query it using: driveService.changes().get(changeId), I intermittently get 404. Am I doing something wrong here?
Watching files:
When watching for file changes, in case of a folder, I want to know about new files added to that folder, so I expected that when adding/removing files from this folder, the "x-goog-resource-state" will hold "add/remove" value while "x-goog-changed" will contain "children".
In reality, the "x-goog-changed" does contain "children", but the "x-goog-resource-state" is always "update", and there is no extra information about the added/deleted file.
Regarding deleted files, I know can get it by watching the file once I have it, but is there a way I can get updated about new files in a certain folder?
I was working on a similar project a few months ago. There are two things you can do to monitor changes on Google Drive :
Set Notification Push using : changes().watch()
Set Notification Push using : files().watch()
The 1st case sends you a request for everything that happens on the Drive you are monitoring, with very little information on what exactly has changed.
The 2nd case is less 'spamming', and you get to decide which folder to monitor.
However the tags on the change type are not accurate. when I was using files().watch() I tested all the use-cases, and I compared the headers of each case.
My conclusions are:
for a new file (or folder) creation inside yourfolder (yourfolder/newfile) the headers contain:
'X-Goog-Changed': 'properties'
'X-Goog-Resource-State': 'update'
which is the same when you move a file to yourfolder, or when you start following an existing file in your folder.
you get 'X-Goog-Resource-State': 'add' when you share with a user
as you can see, the header tags are not accurate/unique.
Also, note that the push-notification channel will not send you requests for files inside a folder inside yourfolder (yourfolder/folder/files). And the channel will expire at some point.
If you still have any questions, or want to know how to implement the code, let me know : )
I have been asked to update a system where header information gets injected into a tif via a 3rd party console application. I don't need to worry about that bit.
The part I have been asked to look at it the merge process that generates the header information.
The current file generated by the process is assumed as correct, before I make any changes, so I want to add this as an approved result, from that I can then check that the changes I make will alter the file as expected.
I thought this would be a good opportunity to look at using ApprovalTests
The problem I have is that for what ever reason the links to the videos are considered corruptible (Possibly show me kittens jumping into boxes or something, which will stop me working, which ironically means I slow down my work done because I cannot see any help videos).
What I have been looking at is the Approvals.Verify and Approvals.VerifyFile extensions.
But what appears to be happening is confusing me.
using VerifyFile creates a received file, but the contents of the file are just a line the name of the file I have asked it to verify.
using Verify(new FileInfo("FileNameHere")) does not appear to generate the received file that I need to flag as approved, but the test does return saying that it cannot find the approved tif file.
I am probably using VerifyFile completely wrong and might be looking at using Verify wrong as well.
useful info?
Might be useful to know, that as this is a legacy application, running as a windows service, I have wrapped the service in a harness that allows me to call the routines, so the files are physically being written elsewhere on the machine outside of my control (well there is a config, but the return of the service I call generates a file in a fixed location if it is successful). I have tried copying that into the Unit Test project, but that doesn't appear to help.
Verify(File) and VerifyFile(string) are both meant to verify an existing file. As such they merely setting the received file to the file you pass in. You will still need to move/approval/create the approved file.
Here is the pseudo code and process.
[UseReporter(typeof(DiffReporter), typeof(ClipboardReporter)]
public void TestTiff()
{
string tif = YourProcessToCreateTifFile();
Approvals.VerifyFile(tif);
}
[Note: if you don't have an image diff installed, like TortoiseDiff, you might want to use the FileLauncherReporter]
Run this, once you get the result, move the file over by pasting your clipboard into a cmd window.
It will move the temporary tif to your test directory with the name ClassName.TestTiff.approved.tif
After that the test should pass until something changes.
Happy Testing!
The timestamps provided by drive.changes.list and drive sometimes do not match. They are close, but the timestamps are off by a few seconds.
We were trying to look at the changes API, and after that pick the revision that has the same timestamp as the one listed in revisions. We are doing this instead of picking the head revision because we do some processing in our app to indicate we've processed a changed file.
Example output demonstrating the issue is as below:
With the changes API I get back:
"modifiedDate": "2013-07-27T12:58:31.854Z",
With the revisions API
GET https://www.googleapis.com/drive/v2/files/0AnwTzqT0JeG7dDFuQmtfbTNzWTd5eWNobllJa014aGc/revisions?key={YOUR_API_KEY}
This is what I get back from drive.revisions.list
"modifiedDate": "2013-07-27T12:58:29.152Z",
Is this a bug? It's preventing us from trying to make a changes call, and then trying to pick the version of the file corresponding to a change.
Changes.list() shows aggregated changes of overall Drive. It can't list changes of every files every single second thus can't be as accurate as file revision. This is not bug. Changes should be mere reference of what's going on on Drive. FYI, you might want to use push notification. This monitors file revisions and tells you whenever changes are made to the file.
Scenario:
I have multiple browser clients whose internet connection varies from very fast to super slow. Because of that they might not see same state of a document.
I'm using Google shortcut file since the document is actually being stored in database.
saving document to database is triggered from client-side.
Question: how do I know which client got the most up to date document that should be saved to the database?
You are right that you can't rely on any particular client being the most up to date at a particular time. There is no easy way to determine that, since that can change at any given instant. (Although you can make sure that you don't have any unsaved changes in a particular client by looking at the document save state.)
Rather than trying to do this based on client state, you can use the export capability that is part of the Drive API, which will give you a valid snapshot of the data with a revision number so you can track what version you have.
Note that this is a brand new feature, so its not yet well documented. The response is a json object with the appId, revision number, and a data field which contains a json version of the document. It looks something like this, for a document that has a collab list "list" and collab string "text" in the root:
{"appId":"788242802491","revision":17,
"data":{"id":"root","type":"Map",
"value":{
"list":{"id":"gde9s8z5khjarls7o","type":"List","value":[]},
"text":{"id":"gdef98qdhiq679af","type":"EditableString","value":"This is a test 2."}}}}
Am reading the Manage-changes documentation, and tried it here. It shows what are the files that get changed/modified after the largestChangeId.
But from this response how do I identify what is being changed exactly!
Say my request with largestChangeId returned one document link. Now I went back to google drive and starrted that specific document. Now when I try the same request with (largestChangeId+1) it returned a new response. How can I identify this change is caused by starring a document? Should this be only manually compared?
Whenever a file is changed, the corresponding entry in the Changes feed will contain a file property with the updated metadata:
https://developers.google.com/drive/v2/reference/changes#resource
Instead of manually comparing properties, you should simply overwrite your local copy with the updated one.