This is a long story. We originally tried this about a year ago with
Ia85c5114, but that was doomed (reverted in Id691318a) as we couldn't
guarantee PatchSet objects wouldn't be written before the inserter was
flushed. That experience directly led to the introduction of
BatchUpdate in I0771f5e8, which finally culminated in converting
MergeOp to BatchUpdate in I1d9883a5[1].
Now, we can close the door on this chapter and finally avoid flushing
each new commit as soon as it's created. It is now easy to prove that
no PatchSets are written pointing to new SHA-1s before they are
flushed, since commits are created in updateRepo and patch sets are
updated in updateChange.
The lone exception is in CherryPickChange, where the BatchUpdate
creation can't easily be hoisted higher, because we have to parse
objects from the repo in order to determine which Change.Id the
operation applies to. But here we can ensure flushing happens by
passing the same ObjectInserter to any BatchUpdates.
This should substantially improve performance of all merge strategies
that create one commit per submitted change (MergeAlways, CherryPick,
RebaseIfNecessary), particularly on slow backends.
[1] The astute reader will notice I have also justified the existence
of BatchUpdate as making the notedb transition easier by being one
place to create ChangeUpdates, enforce ordering, eventually have
retry logic, etc. That is all true, but it turns out it's not the
original motivation.
Change-Id: Icba6262383088fe24b81ec7159511d80ae31724e
fce05db6e4