HQP Refactoring (in Preparation for SQLite Cache)

HQP Refactoring (in Preparation for SQLite Cache)

1. Move ownership of the InMemoryURLIndex from the InMemoryHistoryBackend to the HistoryBackend where it truly belongs.
2. Handle (by notification) URL visits, updates and deletes. Refactor use of NOTIFICATION_HISTORY_URLS_DELETED to provide the deleted URLRow so that row ID is available.
3. Correctly handle the adding and removing of page title words when a URL change is detected.
4. Other small cleanups.

BUG=96731, 92718
TEST=Unit tests updated.
TBR=atwilson (for profile_sync_service_typed_url_unittest.cc)
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=108207

[mrossetti, 2011-11-01 16:12:18]

Peter, this should be the last 'refactoring' change prior to the final
replacement of protobuf with SQLite. Again, you've seen most of these changes
previously.

[mrossetti, 2011-11-01 16:22:42]

Note that win trybot fail is a bot fail and that mac_sync succeeded (though it
is not shown).

[Peter Kasting, 2011-11-01 20:30:24]

LGTM

Somehow it seems weird to me that the HistoryBackend and not the
InMemoryHistoryBackend owns the InMemoryURLIndex.  I guess you know what you're
doing though.

I don't suppose any of these changes fix the problems we have today where
somehow, history auto-expiry and manual deletions via shift-delete don't seem to
update the in-memory index that powers the HUP, causing it to act flaky until we
next restart Chrome?

[mrossetti, 2011-11-01 20:57:16]

On 2011/11/01 20:30:24, Peter Kasting wrote:
> LGTM
> 
> Somehow it seems weird to me that the HistoryBackend and not the
> InMemoryHistoryBackend owns the InMemoryURLIndex.  I guess you know what
you're
> doing though.

There is no dependency at the InMemoryHistoryBackend level any more so this
eliminates a level of indirection.
 
> I don't suppose any of these changes fix the problems we have today where
> somehow, history auto-expiry and manual deletions via shift-delete don't seem
to
> update the in-memory index that powers the HUP, causing it to act flaky until
we
> next restart Chrome?

I doubt it but I will run it through its paces and see if there's been a change.