Index: components/history/core/browser/url_database.cc |
diff --git a/components/history/core/browser/url_database.cc b/components/history/core/browser/url_database.cc |
index 575e8504c3866769d6e865a60102666536f7efc6..eb97fa9b35addc3e5a97ebb5df3fbdb0f4b3a515 100644 |
--- a/components/history/core/browser/url_database.cc |
+++ b/components/history/core/browser/url_database.cc |
@@ -586,13 +586,21 @@ bool URLDatabase::CreateURLTable(bool is_temporary) { |
sql.append(name); |
sql.append( |
"(" |
- "id INTEGER PRIMARY KEY AUTOINCREMENT," |
- // Using AUTOINCREMENT is for sync propose. Sync uses this |id| as an |
- // unique key to identify the URLs. If here did not use AUTOINCREMENT, and |
- // Sync was not working somehow, a ROWID could be deleted and re-used |
+ // The id uses AUTOINCREMENT is for sync propose. Sync uses this |id| as |
+ // an unique key to identify the URLs. If here did not use AUTOINCREMENT, |
+ // and Sync was not working somehow, a ROWID could be deleted and re-used |
// during this period. Once Sync come back, Sync would use ROWIDs and |
// timestamps to see if there are any updates need to be synced. And sync |
- // will only see the new URL, but missed the deleted URL. |
+ // will only see the new URL, but missed the deleted URL. |
+ // |
+ // IMPORTANT NOTE: Currently new tables are created with AUTOINCREMENT |
+ // but the migration code is disabled. This means that you will not |
+ // be able to count on AUTOINCREMENT behavior without adding |
+ // additional migration steps. |
+ // |
+ // TODO(https://crbug.com/736136) figure out how to update users to use |
+ // AUTOINCREMENT. |
+ "id INTEGER PRIMARY KEY AUTOINCREMENT," |
"url LONGVARCHAR," |
"title LONGVARCHAR," |
"visit_count INTEGER DEFAULT 0 NOT NULL," |