tree 06b3991c28be56e67d4a29ad30e9479ecba0a7a8
parent c6ceefd83a9f3e28ce3caaa34f10daa4ede08210
author Shawn O. Pearce <sop@google.com> 1337644910 -0700
committer Shawn O. Pearce <sop@google.com> 1337645407 -0700

Fix duplicated results on status:open project:P branch:B

The changes().byBranchClosedPrev() method does not support pagination
within the database. It only loads all open changes on the supplied
project/branch pair. Because it does not support pagination, we cannot
accept the sortkey_after and limit predicates as part of this rewrite.

AndSource has a special case within it where Paginated sources will
be run again using the sort key from a prior result row whenever
the AndSource has not yet gathered the caller's requested limit
worth of results. When the rewritten predicate ignores sortkey_after
and just returns rows already seen by the AndSource, AndSource assumes
these are new and appends them to the results.

This re-execution of the Paginated (but not really!) ChangeSource
is what causes duplicate results with the topic predicate. But the
topic predicate was just a misleading fact, it actually produces
duplicates anytime the user can see at least one change that matches
the rest of their query string, they see the results repeated out
until the requested pagination limit.

Whenever there are no results, e.g. past the end of pagination, or
there are no matches at all, the server was going into an infinite
loop within AndSource, constantly re-running the same database query
to scan all open changes by the supplied project and branch pair.
This could overload a database server, or Gerrit server with a lot
of unnecessary CPU load.

The correct solution is to declare the ChangeSource to be *not*
Paginated by extending ChangeSource rather than PaginatedSource,
and don't consume the sortkey_after and limit predicates from the
query, allowing those to be applied elsewhere in the query tree.

Change-Id: I25a0171ad23d146c093be1f129fe6f0f41fe7681