BatchUpdate: Create ChangeControl inside transaction

Previously, we were passing in ChangeControls to addOp, which
contained their own defensive copy of the Change object. Callers
already have that ChangeControl instance available, so they might be
tempted to read/write the Change within it inside the body of a
BatchUpdate.Op, which doesn't do what they expect.

Instead, just pass in the Change.Id, and hoist the user setup into the
BatchUpdate creation itself. (This has the side effect of preventing a
single batch update from performing updates on behalf of multiple
users, which is ok.) Push the ChangeControl creation into the
BatchUpdate internals, and use the change that was read in the
transaction rather than depending on a change previously read not in
the transaction and passed in by the caller (via ChangeControl).

This improves consistency in another important way: the Change
instance accessed via ctx.getChangeUpdate().getChange() (aka
ctx.getChangeUpdate().getChangeNotes().getChange()) was read in the
same transaction as the change accessed via ctx.getChange(). (They are
currently still two different instances due to the aforementioned
defensive copy, but that is a quirk we will deal with as we continue
working on notedb update semantics.)

Change-Id: Ifab569aece17a4bcf18b180f2b90b2d5daa3c4ac
This commit is contained in:
Dave Borowitz
2015-10-09 12:00:40 -04:00
parent 9f22f40286
commit a495b26800
12 changed files with 45 additions and 41 deletions

View File

@@ -466,8 +466,10 @@ public class ConsistencyChecker {
PatchSetInserter inserter =
patchSetInserterFactory.create(repo, rw, ctl, commit);
try (BatchUpdate bu = updateFactory.create(
db.get(), change.getDest().getParentKey(), TimeUtil.nowTs())) {
bu.addOp(ctl, inserter.setValidatePolicy(CommitValidators.Policy.NONE)
db.get(), change.getDest().getParentKey(), user.get(),
TimeUtil.nowTs())) {
bu.addOp(change.getId(), inserter
.setValidatePolicy(CommitValidators.Policy.NONE)
.setRunHooks(false)
.setSendMail(false)
.setAllowClosed(true)