Revert 152946 - Replace HistoryQuickProvider protobuf-based caching with an SQLite-based database.

The protobuf-based cache was only being read at startup and written at shutdown. (Except that when the cache could not be read at startup the cache would immediately be saved upon private data reconstruction from the History database.) With the new implementation using an SQLite database for the HQP cache the private data will be restored from the cache database at startup and continually updated during normal operation. There is no need to flush or write the cache at shutdown as it is constantly kept up-to-date.

Detailed comments about the changes made in this CL can be found in the document shared separately.

Previous reviewers: sky, pkasting, shess.

BUG=95686, 95876, 131668
TEST=New tests added, old tests updated, all tests pass.
To manually verify changes:
NOTE: For tests using chrome://omnibox be sure to check the "Show results per provider" and then look at the results for the HistoryQuickProvider.
1) New visits: Type an URL never visited before. Bring up new tab. Start typing the URL or parts of the page title or both and verify that the page is offered as a suggestion.
2) New visits: Type an URL never visited before. Do search using chrome://omnibox. New visit should show.
3) Delete visit: Visit some pages and verify they have been recorded. Bring up history and delete one of the visits. Check via chrome://omnibox that it was deleted.
4) Clear history: Visit some pages. Clear the visit history. Check via chrome://omnibox that none of the visits are still returned by the HQP.
5) Updated site: Create a local page and visit it. Search using chrome://omnibox by page title and verify it can be found. Change the page title dramatically and revisit the page. Verify via chrome://oomnibox that the page can be found by words from the new title.

Previously reviewed as: http://codereview.chromium.org/10477018/.
10477018 was reverted due to memory leaks detected by build bots.
Review URL: https://chromiumcodereview.appspot.com/10837244

TBR=mrossetti@chromium.org

This is causing performance regressions across a range of perf bots.
Review URL: https://chromiumcodereview.appspot.com/10872032

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@152963 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 3 insertions, 5 deletions

diff --git a/sql/diagnostic_error_delegate.h b/sql/diagnostic_error_delegate.h
index 022e6a5..e0c42ba 100644
--- a/sql/diagnostic_error_delegate.h
+++ b/sql/diagnostic_error_delegate.h
@@ -12,10 +12,6 @@
 
 namespace sql {
 
-// The histogram values from sqlite result codes currently range from 1 to 26
-// but 50 gives them room to grow.
-static const int kMaxSqliteError = 50;
-
 // This class handles the exceptional sqlite errors that we might encounter
 // if for example the db is corrupted. Right now we just generate a UMA
 // histogram for release and an assert for debug builds.
@@ -43,7 +39,9 @@ class DiagnosticErrorDelegate : public ErrorDelegate {
     // Trim off the extended error codes.
     error &= 0xff;
 
-    UMA_HISTOGRAM_ENUMERATION(UniqueT::name(), error, kMaxSqliteError);
+    // The histogram values from sqlite result codes go currently from 1 to
+    // 26 currently but 50 gives them room to grow.
+    UMA_HISTOGRAM_ENUMERATION(UniqueT::name(), error, 50);
   }
 };