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:
@@ -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)
|
||||
|
Reference in New Issue
Block a user