What is the difference between recency & viewedByMeTime sort keys in the orderBy parameter of a file's list api
I wanted to get the most recently accessed files through the file's list api. I tried doing so by using recency desc in the orderBy parameter. Although the document suggests that there are mutiple keys based on which the sorting can be done, so what is the difference between recency & viewedByMeTime?
Is viewedByMeTime designed to be used in the context of shared drive?
Recency sort keys : sorts folders and files from the last modified to the first modified
ViewedByMeTime sort keys : as indicated by its name ViewedByMeTime sorts folders and files from the last viwed by the user to the first one.
When nothing is modified and viewed Recency and ViewedByMeTime sort have no effect and the order is kept as it is)
Related
I have a Google Sheet that contains extracted metadata from a large amount of files that I transferred from CDs to a server. I am currently working on creating a description for these materials to include in a finding aid. I found it easiest to work in Excel or Sheets because the PUI we use to output our finding aids utilizes a spreadsheet upload plugin.
I've been using pivot tables in Google Sheets to sort through all of the data with little issue except when I need to generate a date range for the files contained in one CD. Essentially, I'm creating a pivot table that contains rows for the URI, Filename (in this case I'm filtering for folder name only), and date_modified. The data looks something like this:
URI
FILENAME
DATE_MODIFIED
URI1
FOLDER1
2000-01-01
URI1
FOLDER2
2000-01-01
URI1
FOLDER3
2000-02-01
URI1
FOLDER4
1999-12-02
URI2
FOLDER1
2001-01-20
... and so on.
I'd like to generate a date range for each unique URI. I realize I could just go through each unique URI and manually extract that data but I have a LOT of these to go through so I don't think it is the most efficient use of my time. Especially, when you notice that the dates do not follow a chronological order. I'm thinking that pivot tables are not going to help me here so if anyone has other suggestions I'm happy to listen but brownie points if anyone has a solution that works in Sheets!
Try this on a new tab somewhere.
=QUERY(Sheet1!A:C,"select A,MIN(C),MAX(C) where A<>'' group by A")
change the range ref to suit.
Then in the next column over, depending on where you output the query,
=IF(A2="",,TEXT(B2,"yyyy-mm-dd")&"-"&TEXT(C2,"yyyy-mm-dd"))
drag down to the bottom.
I'm working with Apps Script in Slides. The user can select multiple objects on the slide using Shift+Click, and I'm retrieving the selection with SlidesApp.getActivePresentation().getSelection().getPageElementRange().
However, I'm noticing that the order in which the user selects the shapes IS always correct when 2 objects are selected, but is often wrong when 3 or more objects are selected - the ordering with 3+ objects seems to be random and doesn't follow a pattern I can detect.
Any pointers here on how to get the order of the user's selection?
Looks like the pattern is their z-index order (stacking / layering order).
Would be useful to know their selection order, as well as their z-index order.
Can we sort google drive files to show the newest or last modified ones on the top ?? I only can see the list and grid option for showing files in iframe. If not , any advice or alternative solution for this issue that my client is facing it ?
Here is the documentation you needed to list files from the drive.
This method accepts the q parameter, which is a search query combining
one or more search terms. For more information, see the Search for
Files and Team Drives guide.
And you can actually sort it by using the parameter orderBy.
A comma-separated list of sort keys. Valid keys are 'createdTime',
'folder', 'modifiedByMeTime', 'modifiedTime', 'name', 'name_natural',
'quotaBytesUsed', 'recency', 'sharedWithMeTime', 'starred', and
'viewedByMeTime'. Each key sorts ascending by default, but may be
reversed with the 'desc' modifier. Example usage:
?orderBy=folder,modifiedTime desc,name. Please note that there is a
current limitation for users with approximately one million files in
which the requested sort order is ignored.
You can also test by Try it now.
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 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.