| commit | 714f7d3c3f6540b6d52bc4a426476f692eae612c | [log] [tgz] |
|---|---|---|
| author | Edwin Kempin <ekempin@google.com> | Mon Dec 24 10:37:20 2018 +0100 |
| committer | David Pursehouse <dpursehouse@collab.net> | Tue Jan 08 16:43:14 2019 +0900 |
| tree | c1971852c363d75a18380a67ba594e2b25a9762c | |
| parent | d8e89a879fd59f195b1f9b03d7296bb80e644b34 [diff] |
Fix sorting of results from Lucene for account, group and project index The fields that are used for sorting must be added to the document. This means the documents in the index must be all recomputed, hence we need new index schema versions for the affected indexes. The sorting that is done by Lucene for the account index must match the sorting of accounts that is already done in QueryAccounts before returning query results to clients. QueryAccounts sorts results by fullname, preferred email and account ID. If Lucene would do a different sorting limited queries may return wrong results. E.g. if there are 3 accounts, Foo (ID=1), Bar (ID=2) and Baz (ID=3), which are all matched by a query for which the results are limited to 2, callers of QueryAccounts expect Bar and Baz to be returned since QueryAccounts promises sorting by fullname. If now Lucene would sort by account ID, Lucene would find Foo and Bar, Baz would be skipped since it's over the limit. These results are then handed over to QueryAccounts which does sorting by name so that Bar and Foo are returned to the client. This would be wrong since the caller expects Bar and Baz. It's a bit unclear how this worked when Lucene was not doing proper sorting at all, maybe it was just luck that the withLimit test succeeded before. As Lucene does the sorting properly now, the sorting in QueryAccounts could be removed, but since Lucene is not the only index implementation and other index implementation may still have sorting issues we keep that sorting in QueryAccounts for now. Bug: Issue 10210 Change-Id: Ic59e4d330fe8c7198023ddbc2fa946cf5db80b63 Signed-off-by: Edwin Kempin <ekempin@google.com>
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 IRC channel on freenode is #gerrit. An archive is available at: echelog.com.
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.