tree b38b6b24b7360563c99034c75c807132295c4ed2
parent f7cc0f4043b2476e4cd0a64b79ccc3078edcfa5a
author Dave Borowitz <dborowitz@google.com> 1498165425 -0400
committer Dave Borowitz <dborowitz@google.com> 1498247949 -0400

Finish NoteDbMigrator

The final phase is converting all changes to NoteDb primary. This is
very straightforward, as PrimaryStorageMigrator was designed to be run
in arbitrary order with arbitrary parallelism.

The only tricky thing is that this phase changes to _NOTE_DB_PRIMARY
before doing any work, then NOTE_DB(_UNFUSED) after. The only way it's
possible to iterate through the main state loop in _PRIMARY is if there
was a failure, in which case we run the failed step again on the next
execution.

This exposed one now-faulty assumption in the NoteDbBatchUpdate
implementations that the specific ReviewDb instance handed to the
constructor has its changes tables disabled. It's possible for the
config read from the NotesMigration to determine which BatchUpdate
implementation to use to differ from the bits used by
NotesMigrationSchemaFactory at context creation time to open a ReviewDb.
There's no harm in removing these overly-conservative checks.

Change-Id: I0a7def4dc7e1da18eb928920b2538225fc6fea57