Add field to monitor last visited time for each search engine

components/webdata/common/web_database.cc

Index: components/webdata/common/web_database.cc
diff --git a/components/webdata/common/web_database.cc b/components/webdata/common/web_database.cc
index 5cb4c42399ec8eca76a2438d0ca35f11bfc3e5e7..04b4d4fe1ec47bb8c8951ccde777d01ad275e671 100644
--- a/components/webdata/common/web_database.cc
+++ b/components/webdata/common/web_database.cc
@@ -13,13 +13,13 @@
 // corresponding changes must happen in the unit tests, and new migration test
 // added.  See |WebDatabaseMigrationTest::kCurrentTestedVersionNumber|.
 // static
-const int WebDatabase::kCurrentVersionNumber = 68;
+const int WebDatabase::kCurrentVersionNumber = 69;
 
 const int WebDatabase::kDeprecatedVersionNumber = 51;
 
 namespace {
 
-const int kCompatibleVersionNumber = 68;
+const int kCompatibleVersionNumber = 69;

[Peter Kasting, 2016/11/21 03:35:08]

I wouldn't update this; see comments elsewhere.

[ltian, 2016/11/28 22:08:02]

Sorry I am a little confused about when should code update this
|kCompatibleVersionNumber| field? Say if the change is about addition of a new
field, does |kCompatibleVersionNumber| have no need to be changed? Or it is also
related to whether it is optional or not? If so, how to learn/decide whether the
newly added field is optional or not?

[Peter Kasting, 2016/11/28 22:20:24]

From a chat we had a few weeks ago: "The compatible version is the minimum
version of Chrome that could safely read and write the data table from the
current version."

So, if we add this last_visited column, and then an old version of Chrome wants
to use the data file, can it?

The answer is yes: when reading data out of the file, it won't SELECT the
last_visited column, so it won't read that data into anywhere.  When writing
data out, it won't update/reset this column, which is fine, since the only
effect of that is that a visit made in an old client won't be recorded for the
purpose of bumping that engine in the "recently visited" standings, and we can
live with that.

Basically, column removals should always bump the compatible version (since they
will break old code trying to read them), but column additions may or may not
bump it, depending on what the consequences are if old code adds or updates the
overall entry without touching that column.  Since in this case things will
degrade reasonably gracefully, we're OK not bumping the version.

 
 // Change the version number and possibly the compatibility version of
 // |meta_table_|.