commit | 094f02c20097c221cf8cb6ec8d99627669207e51 | [log] [tgz] |
---|---|---|
author | Patrick Hiesel <hiesel@google.com> | Thu Oct 10 17:55:34 2019 +0200 |
committer | Patrick Hiesel <hiesel@google.com> | Fri Oct 11 10:54:19 2019 +0200 |
tree | f016c64c0922b8a9e2d9ed7fb93e80ed1bceaae9 | |
parent | 1673f18a424f1bbe431af59cb2e472b701033692 [diff] |
Fix a bug where _moreChanges is set to the wrong value The query changes REST endpoint supports sending multiple queries in a single request. The backend implementation uses a cache (a simple map) to spare computing a ChangeInfo object more than once in case it shows up in more than a single query result. The implementation contained a bug that would set _moreChanges on the last entity of one query that has more results than get sent. However, through the reuse of the entity, this boolean would also end up in other entities, where it's simply wrong. There are multiple, alternative ways how this can be fixed: 1) Remove the cache: We could simply remove the map. This has an unknown performance impact. 2) Deep-copy objects instead of plainly reusing them: This would add boiler-plate to a lot of *Info objects that ChangeInfo depends on. Hopefully we can consider moving to immutable API objects (AutoValue or Protobuf) in the future, which would obsolete this code. It still seems undesirable to add this now. Notably, ActionJson already contains what looks like brittle copy logic. 3) Rework the JSON response to be a List<QueryResponse> where QueryResponse is an object that has List<ChangeInfo> and _more: Would be the right path design-wise, but is a non-starter because it's a major change to a heavily used API. 4) Never reuse the last entity in a result set: In this way, the last entity is always unique. Setting _moreChanges on it has no side effects. This commit implements (4), which seems like the least evil. Change-Id: I6b007d442249d0445ea49f125c45d8f9022e104e
Gerrit is a code review and project management tool for Git based projects.
Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.
For information about how to install and use Gerrit, refer to the documentation.
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Please report bugs on the issue tracker.
Gerrit is the work of hundreds of contributors. We appreciate your help!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
The Developer Mailing list is repo-discuss on Google Groups.
Gerrit is provided under the Apache License 2.0.
Install Bazel and run the following:
git clone --recurse-submodules https://gerrit.googlesource.com/gerrit cd gerrit && bazel build release
The instruction how to configure GerritForge/BinTray repositories is here
On Debian/Ubuntu run:
apt-get update & apt-get install gerrit=<version>-<release>
NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.
On CentOS/RedHat run:
yum clean all && yum install gerrit-<version>[-<release>]
On Fedora run:
dnf clean all && dnf install gerrit-<version>[-<release>]
Docker images of Gerrit are available on DockerHub
To run a CentOS 7 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-centos7[:version]
To run a Ubuntu 15.04 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-ubuntu15.04[:version]
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.