带有'not'参数的Drive API files.list查询返回空页面

Question

我正在使用Drive API列出集合中的文件，这些文件的标题中不包含某个字符串。

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

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

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

我还在尝试一些用例，但似乎它与“not”运算符有关。就像请求是在没有它的情况下进行的，因此返回5页，但结果与响应中的请求相对应。这对我来说非常令人不安，因为我在这里寻找最好的表现，显然不得不向驾驶而不是一个单打5个请求对我不利。我也注意到结果并不总是出现在最后一页。我用另一个集合进行了测试，结果显示在第二页，但之后我仍然得到3个空页。

我在这里遗漏了什么吗？这种行为“正常”吗？我的意思是想象一下，如果我的收藏中有1000个文件，不得不提出50个请求，只找到一些不是我所期望的。

Answer 1

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

据我所知，Drive API以这种方式运作：

1. 检测与您的查询最匹配的索引
2. 使用步骤1中的索引选择前20个记录
3. 应用您的过滤器：删除与您的查询不匹配的记录
4. 使用下一页令牌向您返回休息（可能为空）。

nextPageToken在下一页的第一条记录中看起来只有OFFSET，可能包含一些关于查询或索引的信息。

在base64解码此令牌后，我在解码令牌的第121位找到了下一个结果的相应记录号。 以前我使用maxResults=1构建了令牌索引。

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

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

只有你可以做的是pagenage并跳过空结果。不要忘记请求数量的限制。

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

Answer 2

目前

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