tree 3756ef41fdad49d021d00cb6027d1bec1b717da6
parent 87d682b755daf85213e787b242619ce6f874353d
author Dave Borowitz <dborowitz@google.com> 1431986410 -0700
committer Dave Borowitz <dborowitz@google.com> 1432323792 -0400

Convert GetRelated to use patch set groups where present

Query for any changes matching any of the groups of all patch sets of
the change being viewed. Once we have the full list of candidate
changes, determine which patch set we are interested in for the
change, since we only display a single patch set of a change in the
Related Changes tab. For each matching change, prefer the latest patch
set that has at least one group in common with the patch set being
viewed. But such a patch set may not be present, for example if a
later change has not been rebased; in that case, just pick the latest
patch set of the change.

For a live migration, if there is a groups field on the patch set
being viewed, assume that a new patch set of that change and any
ancestor changes has been pushed since the groups code started
running, and use the secondary index for the search. (Note that this
assumption does not always hold for descendant changes, which might
not get new patch sets at the same time. But it should usually hold.)

If the field is null, default to the old PatchSetAncestors
implementation; this covers all existing open changes in a live server
without requiring a migration step immediately. We will still likely
want to migrate existing groups of open changes when removing the
PatchSetAncestors table, however.

This feature can be turned off with an undocumented config option.
This option is intended only to support testing and live migrations,
and will be removed before the stable release containing this feature.

Change-Id: I8d9030db018b64ea947976274115567a08def4b9