commit fd6ace75951040f1fc5e0dc0c8e7b55b7e0ed05c
author Dave Borowitz <dborowitz@google.com> Fri Jan 15 10:13:53 2016 -0500
committer Dave Borowitz <dborowitz@google.com> Fri Jan 15 10:30:23 2016 -0500
tree ea9ea16a74027ea294bca8dff5be12db404e50e0
parent feda0ff046d0bbe5aa4255f28f29bc24bdb79c86

BatchUpdate: Update/insert/delete change exactly once

The gwtorm backend for gerrit-review has the very unfortunate property
of not supporting multiple updates to the same entity in one
transaction. This has always been the case, but the recent
reorganization of most update code into composable BatchUpdate.Ops has
brought the issue to the fore: different Ops in different locations
may update different parts of an entity, and may all reasonably want
to call changes().update(c) to save their updates.

Prior to the BatchUpdate refactoring, this was not a problem, because
there was less use of transactions. But now that we're doing more
things in transactions (which, remember, is generally a good thing for
performance reasons), this is more likely to crop up.

Wrap the ReviewDb available to ChangeContext with one that does not
support directly modifying the changes table, and replace it with a
handful of *idempotent* methods for indicating that the change should
be updated later. This loses the ability to read back changes that
were previously written in the transaction, but since all Ops should
share a common ChangeContext instance and hence a common mutable
Change instance, they can just read from that.

This change only solves the problem for the Changes table. However,
that should be the most common place where this crops up, since there
are so many fields in Change. Other operations tend to modify
non-overlapping entities (Idd16eaef notwithstanding), for example
one op inserts a new PatchSet and another op adds a ChangeMessage.

Change-Id: Ie7236c2630707df70d452b3f9c014d5591e36aaf