commit 9db5a7462da8610efd403abf80661cf4b15e0618
author Dave Borowitz <dborowitz@google.com> Tue Nov 13 16:40:25 2018 -0800
committer Dave Borowitz <dborowitz@google.com> Fri Dec 07 08:22:29 2018 -0800
tree 62e3ea1d74420655f6ca9e4234f670d2e624ca69
parent 2a84138f06e0579991c6f3673015b491b4d3e081

NoteDb schema upgrades

Analogous to the schema version number in the CurrentSchemaVersion
table, store the current schema version in NoteDb as an int blob in
refs/meta/version in All-Projects. Version numbers start at 180, which
continues the numbering and class naming scheme from ReviewDb, plus a
gap to allow for a last few schema upgrades in the stable-2.16 branch.

Although NoteDb gives us the flexibility to do more interesting things
in terms of out-of-order or optional schema upgrades, this
implementation sticks to the old ReviewDb way of doing things with a
single monotonically increasing version.

The implementation is roughly similar to the ReviewDb implementation,
where we have NoteDbSchemaVersion{Check,Updater} classes to enforce that
the running server has been fully upgraded, and a simple loop run during
init to upgrade the schema. To make NoteDb migration tests pass with
GERRIT_NOTEDB=OFF, these only take effect when NoteDb is enabled at
setup time. In reality, this hack is short-lived, since we will be
removing ReviewDb support entirely quite soon.

The main difference in implementation is that we no longer construct
NoteDbSchemaVersions using Guice, and instead require a certain
constructor signature for implementations. Not constructing these via
Guice also allows us to do away with the chained
Provider<Schema_$PREVIOUS> constructor arguments. These historically
caused Guice performance problems, which is why they got converted to
Providers in the first place. Rather than preserve that hacky logic,
just don't use Guice. This is not such a painful amount of reflection.

For now, leave the ReviewDb schema upgrade code around, so technically
we can upgrade both ReviewDb and NoteDb schemas in a single binary. In
practice, however, a followup change should be able to completely delete
all old schema upgrade code.

No additional work is done in this series in order to accommodate any
last-minute schema upgrades on the stable-2.16 branch. In order to allow
admins to upgrade directly from 2.16, even if there are new upgrades in
2.16.1 or later, we will have to add idempotent NoteDb schema upgrade
implementations of those upgrades. This is a small amount of extra work,
but there should not be many of these. It also does not require any
additional support in this change.

Change-Id: Ibd2868b8de8de023c8f2c661e2ce3a2b21f3a2f5