Drive API files.list返回空白項目結果的nextPageToken

在上週左右，我們在應用程序的文件列表中收到了用戶丟失文件的報告。起初我們有點困惑，因爲他們說他們只有幾個文件與我們的查詢字符串相匹配，但通過一些工作，我們可以通過向我們的Google Drive添加大量文件來重現問題。之前我們一直假設人們只有不到100個文件，並且沒有進行分頁以避免多個file.list請求。Drive API files.list返回空白項目結果的nextPageToken

切換到使用分頁後，我們注意到我們的一個測試帳戶發送了數百個和數百個files.list請求，大多數響應沒有包含任何文件，但包含nextPageToken。我會盡快更新屏幕截圖 - 但客戶端發送了足夠的請求來加熱計算機並快速耗盡電池。

我們還發現，根據查詢的內容，即使它匹配相同的文件，它也會對檢索我們的完整文件列表所需的請求數量產生嚴重影響。例如，在查詢參數中將'='切換爲'包含'會顯着減少所做請求的數量，但我們沒有看到任何保證這是一個合理的和一般化的解決方案。

這是預期的行爲？我們可以做些什麼來減少我們發送的請求數量？

我們正在使用以下代碼來檢索由導致問題的應用程序創建的文件。

runLoad: function(pageToken) 
{ 
    gapi.client.drive.files.list(
    { 
     'maxResults': 999, 
     'pageToken': pageToken, 
     'q': "trashed=false and mimeType='" + mime + "'" 
    }).execute(function (results) 
    { 
     this.filePageRequests++; 

     if (results.error || !results.nextPageToken || this.filePageRequests >= MAX_FILE_PAGE_REQUESTS) 
     { 
      this.isLoading(false); 
     } 
     else 
     { 
      this.runLoad(results.nextPageToken); 
     } 
    }.bind(this)); 
}

來源

2014-07-21 Grant Watters

這是，但可能不應該是正確的行爲。

它通常發生在使用drive.file作用域時。（我認爲）發生的是API層獲取所有文件，然後刪除當前範圍/查詢之外的那些文件，並將其餘部分返回給客戶端應用程序。理論上，特定頁面的文件可能沒有範圍內的文件，因此返回的數組是空的。

正如你所看到的，這是一個非常低效的方式，但這似乎是它的方式。你只需要繼續關注下一頁鏈接，直到它爲空。

至於「我們可以做些什麼來減少我們發送的請求的數量？」

您已經將最大結果設置爲999，這是很明顯的一步。請注意，我已經看到這個值觸發內部錯誤（超時？），它們表現爲500錯誤。您可能想要犧牲效率來提高可靠性，並堅持默認值100，這似乎是更好的測試。

我不知道你發佈的代碼是你的實際代碼還是隻是一個簡單的插圖，但你需要確保你正在處理401錯誤（auth過期）和500錯誤（有時可恢復與重試）

來源

2014-07-22 15:56:43 pinoyyid

是的 - 他們有兩個步驟，一個是在索引上，另一個是後處理步驟，用於刪除結果。任何導致第二個後處理步驟的結果都會計入maxResults數字，該數字就是導致空白頁面的原因（如您所說）。然而，令我困惑的部分是，在一種情況下，我們使用'='來檢查mimeType並切換到使用'contains'。這實際上*減少了我們得到的頁數（在一個例子中）並且看起來像意想不到的行爲。 –

@GrantWatters，這是過濾在不同層次上發生的副作用。顯然不理想，但這就是目前的工作方式。 –

我更新了我的答案，以部分解決「我們能做些什麼來減少我們發送的請求的數量？」 – pinoyyid

Drive API files.list返回空白項目結果的nextPageToken

回答

相關問題