2

我正在使用 Drive API 列出标题中不包含特定字符串的集合中的文件。

我的查询看起来像这样： files().list(q="'xxxxx' in parents and not title contains 'toto'")

在我的驱动器集合中，我有 100 个文件，除了 10 个文件之外，所有文件的标题中都包含字符串“toto”。

我正在使用分页来检索 20 到 20 的结果，所以我希望只得到一页，其中包含与我的请求相对应的 10 个文件。令人惊讶的是，API 返回了 5 个页面，前 4 个页面没有结果，但有一个 nextToken 页面，符合我的请求的文件只有第五个页面。

我仍然在这里尝试一些用例，但它似乎与“非”运算符有关。就像在没有它的情况下发出请求一样，因此返回 5 个页面，但结果与从响应中删除的请求不对应。这对我来说非常令人不安，因为我在这里寻找最佳性能，显然必须向 Drive 发出 5 个请求而不是一个请求对我不利。我还注意到结果并不总是出现在最后一页。我用另一个集合进行了测试，结果显示在第二页，但在那之后我仍然得到 3 个空白页。

我在这里错过了什么吗？这种行为“正常”吗？我的意思是想象一下，如果我的收藏中有 1000 个文档，那么必须发出 50 个请求才能找到其中的几个，这不是我所期望的。

4

2 回答 2

1

我在 files.list API 中有类似的问题。我试图接收根文件夹下的所有三个文件夹。我只在第 342 页收到了结果。经过几个小时的研究，我发现这种奇怪的行为有一定的规律性。

据我了解，Drive API 以这种方式工作：

  1. 检测与您的查询最匹配的索引之类的东西
  2. 使用步骤 1 中的索引选择前 20 条记录
  3. 应用您的过滤器：删除与您的查询不匹配的记录
  4. 剩下的将与下一页令牌一起返回给您（可能为空）。

nextPageToken 看起来就像OFFSET决定索引中下一页的第一条记录，可能它包含一些关于查询或索引的信息。

在 base64 解码此令牌后，我在解码令牌中的第 121 位找到了下一个结果的适当记录号。以前我使用maxResults=1.

这很疯狂，但我对可观察到的行为没有其他解释。

它对服务器非常有用，因为服务器为搜索做的工作非常少。另一方面，该算法必须产生大量分页整个列表的请求。但是每秒请求数的限制解决了这个问题。

只有你能做的是分页并跳过空结果。不要忘记请求数量的限制。

不要试图找出你身边的错误。这就是 Google Drive API 的工作原理。

于 2014-02-03T08:59:30.363 回答
0

contains运算符目前正在用作前缀匹配器。title contains 'toto'将匹配“totolong”和“toto”，但不匹配“blahtoto”。

于 2013-09-05T22:38:23.923 回答