I am integrating Box into my app using the Java SDK and I would like to know whether or not there is a good way to use the search API call to get an item id by path.
The app can potentially have 100k + files and I need a reliable way to get the box id of a path (folder or file).
I was considering using a folder traversal as suggested by answers to similar questions, but given the number of files that may need to be traversed I'm worried about hits in performance.
Is using the search API call a good replacement for this?
Is there a way to restrict the query just to the name field of the item?
Is there a way to get only exact matches?
Will this perform potentially worse than doing a folder traversal?
Thanks,
George
Is using the search API call a good replacement for this?
No, the search API will be sorted by Box's search relevance algorithm and may not map to what you want.
Is there a way to restrict the query just to the name field of the item?
Not currently.
Is there a way to get only exact matches?
Not currently.
Will this perform potentially worse than doing a folder traversal?
Probably, because you aren't guaranteed to get an exact match.
Related
I want to access the original maxspeed tag of the OSM edges when using a OSRM query (e.g., routing service with annotations=true).
It seems that OSRM does not provide by default a way to access the original tags of OSM when querying.
After some google-fu it seems that this may be possible with a custom lua profile, but I'm not sure.
Having said that, is there any way to get the maxspeed tag information in a OSRM query?
No we don't preserve the original maxspeed information. A common way to expose this information is to use some external data source to annotate the route after the fact.
OSRM exposes the OSM IDs of all nodes travel if you pass annotations=nodes option. The nodes will be in the .routes[].legs[].annotations.nodes property. You could combine this with a tool like the route-annotator, seems like they are currently working on exposing this information easily.
I can get a list of summaries of violating sites, using the following link:
https://developers.google.com/ad-experience-report/[...]/violatingSites/list
My questions:
Is this list exhaustive?
If not, is it possible to get an exhaustive list (or not) and how?
Is it possible to know how these websites are pulled (the share of websites analysed, etc)?
- Is this list exhaustive?
What's size of your actual API return?
If you have an API return statement increasingly longer and longer with new data at each new request, you can think have the exhaustive list (with a possible update
latency).
If the API return statement have always same size with different data, in example old data will not appears and it replaced by new data, it's not exhaustive.
- If not, is it possible to get an exhaustive list (or not) and how?
I have no idea at the moment, the total number of websites can be in billion ...
- Is it possible to know how these websites are pulled (the share of websites analysed, etc)?
I have no idea for the moment too, I think it is either a confidential process or that it is described in the general conditions and subtily in the documentation...
Short version:
What is the proper way to list/query files by suffix, "fullText contains 'ext', "fileExtension = 'ext'" or "title contains 'ext'"? These do not always return the same results; only one of them is documented (the first), and it's not consistent.
Long versions:
I've been developing Google Drive apps for years. Every now and then I have to change to my list queries to get the correct results. My application needs to find files with a certain suffix. Official documentation indicates that I need to use the "fullText contains 'ext'" syntax, but sometimes this fails to find some files. At one time I switched to the undocumented "fileExtension = 'ext'" syntax, but again after some time I found files that wouldn't show up and went back to fullText searches. However, again I've seen files not showing up with that search and tried using "title contains 'ext'" (or v3 "name contains 'ext'") which seems to work, but for how long? I don't like using undocumented queries which might just suddenly stop working.
I feel like I'm going in circles since I don't know why fullText fails (and only for some users, and when it does work I've seen the parents field come up empty sometimes...which doesn't happen with other queries) or why the title search works (not documented to search suffixes...and I'm pretty sure it didn't used to work). I might just perform all three searches, but this affects performance, and the "or" keyword with some combinations of those three searches returns no results at all.
My application has thousands of files, each with multiple revisions, in hundreds of folders and each folder is shared with dozens of users and those permissions are changing on a regular basis as people are added and removed from projects. There are hundreds of different owners of the individual files. I suspect this complexity and the time it takes to propagate permissions and file changes affects my queries, but doesn't explain why one search would work and another wouldn't or why the information returned on a file in one query would be different from the other. That is, even after several days the problem doesn't correct itself and often a file must be remove and re-uploaded for everyone to see it. I have experienced the slow updates to meta data for shared files resulting in mismatches between meta data, files, and search results, but I take all of that into account and still have queries which simply won't work properly.
Maybe I'm expecting too much from a free API? Overall I'm very happy with what i can do, but it can be very frustrating when it's not working and you know you're doing it right! :)
You can search or filter files with the 'files.list' or 'children.list' methods of the Drive API. These methods accept the 'q' parameter which is search query.
For more information, see: https://developers.google.com/drive/v3/web/search-parameters
I need to fetch a list of all the files in a user's box account, such that the list of files can then be displayed in a table view (iOS).
I have successfully implemented this by recursively using /folders/{folder id}/items on all the folder's in my user's box.
However, while this works, it's kind of dirty, seeing as how a request is made for each of the users's folders, which could be quite a large number.
Is there any way to get a list of all the files (it's no issue if folders are included, I can ignore those manually) available?
I tried implementing this using search, but I couldn't identify a value for the query parameter that returned everything.
Any help would be appreciated.
Help me, Obi-Wan Kenobi. You're my only hope.
What you are looking for (recursive call through a Box account) is not available. We have enterprise customers will bajillions of files and millions of folders. Recursively asking for everything would take too long.
What we generally recommend is that you ask for as little as you can, and that you use multiple threads and anticipate what you'll need just a little bit, so that you can deliver a high-performance user-interface to your end-users.
For example ?fields=item_collection is expensive to retrieve, and can add a lot to a paylaod. It can double, or 10x the time that it takes to get back a payload from the Box API. Most UI's don't need to show all the items inside every folder. So they are better off asking for ?fields=.
You can make your application responsive to the user if you make the smallest possible call. Of course there is a balance. Mobile networks have high latency, and sometimes that next API call to show some extra thing is slow. But for a folder tree, you can get high performance by retrieving only the current level, displaying that, and then starting to fetch one-level down while the user is looking at the first level.
Same goes for displaying thumbnails. If a user drills into a folder and starts looking at thumbnails for pictures, there's a good chance they'll want to see other thumbnails in that same folder. Your app should anticipate that, and start to pull one or two extras down in the background. Yes, it means more API calls, but your users will give your app a higher rating for being fast.
I want to store a large number of unique, indexable urls in mysql. They will be written by the user and will have a really broad acceptance, so almost anything goes there.
But I don't like the already answered SO question nor it's predecessor. Actually I think there might be a 'better' way for doing so, but I don't completely see the implications of this, so that's why I ask this question.
What are the advantages/disadvantages of using tinyurl.com's API for this purpose? In this link we can see an article about how to do this. It's just this code (could be even shorter but I prefer it in a function):
function createTinyUrl($strURL)
{
return file_get_contents("http://tinyurl.com/api-create.php?url=".$strURL);
}
Then I would have to compare only the example in tinyurl.com/example to check the uniqueness of the link. From the wikipedia article we can read:
If the URL has already been requested, TinyURL will return the existing alias rather than create a duplicate entry.
Disadvantages (basically same ones as using any centralized system):
Tinyurl servers could go down temporarily or forever. Just in case, the full url will be stored in another not-indexed field.
Non reversible. You can get a tinyurl from your url, but the other way back is more difficult. However, first problem's solution also solve this.
In my case, the urls are NOT private, but this could prevent someone from using this solution.
Delay. The requests might be a bit slower, but since it's server to server talking, I don't think this will be noticeable. Will do some benchmark though.
Any other disadvantage that you can see using this method? The main reason for using it is not to have duplicated entries and to make them indexable.
As the user eggyal suggested, a hash based index of the full URI is really similar to using the Tinyurl API, only I don't need to send data anywhere. I will use that then.
NOTE: this answer is here only to add closure to the question