sql::MetaTable.next_download_id, DownloadManager::GetNextId()

chrome/browser/download/download_history.cc

Index: chrome/browser/download/download_history.cc
diff --git a/chrome/browser/download/download_history.cc b/chrome/browser/download/download_history.cc
index 115541a4d24742ed52fa9ed9683f915109b60175..ff5d2447caa207c442b424bfc9dd8ba48d5737c1 100644
--- a/chrome/browser/download/download_history.cc
+++ b/chrome/browser/download/download_history.cc
@@ -33,6 +33,17 @@ DownloadHistory::~DownloadHistory() {
     delete i->second.second;
 }
 
+void DownloadHistory::GetNextId(
+    HistoryService::DownloadNextIdCallback* callback) {
+  DCHECK(callback);
+  HistoryService* hs = profile_->GetHistoryService(Profile::EXPLICIT_ACCESS);

[Randy Smith (Not in Mondays), 2011/07/25 20:20:12]

So just a note: It turns out that this means that regular and incognito profiles
will share an id space.  I don't think this is a problem, but I watned to make
sure you were aware of it too.

[benjhayden, 2011/07/27 19:40:54]

Yes, OTR downloads are not persisted, and the DownloadIds will be distinct
because the DM*s are distinct.
However, OTR chrome://downloads shows both the otr downloads and the on-record
downloads, so it seems that chrome.downloads.search() should return both kinds
of downloads and that the ids should not collide.
I think I'm going to forward otr GetNextId() calls to the on-record DM so that
extensions in otr windows don't have id collisions.
As you say, allowing the ids to collide until the extensions api is in place
shouldn't break anything. 

[Randy Smith (Not in Mondays), 2011/07/28 21:03:16]

Sounds good.  Answers my question on your other CL, too :-}.

[benjhayden, 2011/08/03 17:44:46]

Done.

+  if (!hs) {
+    delete callback;
+    return;
+  }
+  hs->GetNextDownloadId(&history_consumer_, callback);
+}
+
 void DownloadHistory::Load(HistoryService::DownloadQueryCallback* callback) {
   DCHECK(callback);
   HistoryService* hs = profile_->GetHistoryService(Profile::EXPLICIT_ACCESS);