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.
Related
Sorry - I'm a total newbie with InstallShield. I've inherited an InstallShield 2013 project that presents the user with a dialog that let's the user select a SQL Server and based on their selection sets a value in a config file. That's not working, so I opened the project in IS and looked in the Text File Changes under System Configuration and there's nothing there that would do this. So how do I figure out where this is happening (or not happening in my case), and then how do I get it to work? I need to set both data source and initial catalog in a file called server.config.
So how do I determine what the user selected and then save that in this file? It looks like I can set up a Text File Change, but how do I access the values selected by the user? And how can I figure out where the "code" is that is supposed to be doing this?
Thanks,
Ben
I would try to track this from the dialog and controls in question, or by following the value through a verbose log. Since you say it doesn't work today, there will probably be an interruption in the flow I describe below, and since you don't know the full state of the installation project, it may be hard to identify. So search from what you know.
Top down: what gets configured
First, find the dialog that you fill out as a user making the selection. Then figure out the property that the particular control is associated with. Now you've got a thread; pull on it.
Search in the direct editor for references to the property. If the property is named MYCONFIG search for just that: MYCONFIG. You'll probably find some sort of use that looks like [MYCONFIG] instead, which is typically a format string specifying to use the value of MYCONFIG. You may also have to search all the files related to your project, as Custom Action implementations can be code stored outside of your InstallShield project.
The use may be in a ControlEvent, CustomAction, or some other table. If it's in a ControlEvent, it may be used to set another property. Ditto if it's in a CustomAction that sets properties (type 51) which may be easier to understand in the Custom Actions and Sequences view. In that case, also search for the property that gets set.
If you find it in a table like ISSearchReplace* or ISXml*, or IniFile, it's probably part of the Text Files Changes, XML File Changes, or INI File Changes, and that view should make it easier to understand.
Maybe that thread dead-ends somewhere. A property gets set, but never referenced. So try to search from the other end.
Bottom up: what gets written
If there are text file changes, xml file changes, ini file changes, or custom actions that reference the file you need updated, see where they get their information. Try to follow it back. If they're well written, you should be able to identify the property (noting that one called CustomActionData comes from a property matching the name of the custom action it's used in), and then trace that further back using the same ideas as above, but in the other direction.
Where's the problem?
If the threads don't connect, that's probably the problem. It's also possible that a custom action lacks permissions but doesn't reports a failure, or that the file name or path got misconfigured somewhere along the way. Look for small things like that if things look like they should work but don't.
It turns out that I misunderstood the problem and the project was never set up to change that value, so all I had to do was set up a Text File Change and it works perfectly. Thanks #Michael Urman for the thorough response - I really appreciate it!
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 : )
The matbpotlib documentation describes the order in which "matplotlib looks for matplotlibrc" files, but it is unclear whether the first matplotlibrc file encountered completely determines the rc settings, or whether only those values set in a given file are used.
Does the first matplotlibrc file encountered completely determine matplotlib's configuration, or are settings absent from a given file sought in files later in the search order?
Yes, it only reads the first file it hits. The rest of the values are filled in from the defaults. The relevant functions are in __init__.py.
There is a PR (which will hopefully be merged to master soon) which allows you to load 'style sheet' like rcparam files to set just some of the parameters.
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.
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.