opendev/gerrit
Code Issues Proposed changes

Support pagination using offsets instead of sortkey

Browse Source 
We cannot guarantee that secondary index implementations (particularly
the one used by googlesource.com) can efficiently paginate based on
the sortkey, and in particular can both sort and reverse sort on the
same field. This particular performance issue notwithstanding,
searching is now generally fast enough that it is feasible just to
skip the first N results when doing pagination.

Add an option S= to QueryChanges to support starting at a nonzero
offset. Note that we still have to fetch n+S results from the index in
order to do visibility filtering, since if we skipped at the index
layer we wouldn't know how many of the skipped elements would have
matched later filtering.

Drop the sortkey token suffix from the legacy anchor parser; there is
no reliable way to convert it to an offset, and it's unlikely that
users have permalinks to specific sortkey values.

On the server side, remove the sortkey field from the current index
version, and use pagination by offset instead of sortkey in the new
version only.

Continue to support sortkey queries against old index versions, to
support online reindexing while clients have an older JS version.

Change-Id: I6a82965db02c4d534e2107ca6ec91217085124d6
This commit is contained in:
Dave Borowitz
2014-02-10 15:58:20 -08:00
parent a0af7febe6
commit 86caf9ec23
40 changed files with 645 additions and 387 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
gerrit-lucene/src/main/java/com/google/gerrit/lucene/QueryBuilder.java
View File

@@ -179,28 +179,46 @@ public class QueryBuilder {
false, false);
}
@SuppressWarnings("deprecation")
private Query timestampQuery(IndexPredicate<ChangeData> p)
throws QueryParseException {
if (p instanceof TimestampRangePredicate) {
TimestampRangePredicate<ChangeData> r =
(TimestampRangePredicate<ChangeData>) p;
return NumericRangeQuery.newIntRange(
r.getField().getName(),
toIndexTime(r.getMinTimestamp()),
toIndexTime(r.getMaxTimestamp()),
true, true);
if (r.getField() == ChangeField.LEGACY_UPDATED) {
return NumericRangeQuery.newIntRange(
r.getField().getName(),
toIndexTimeInMinutes(r.getMinTimestamp()),
toIndexTimeInMinutes(r.getMaxTimestamp()),
true, true);
} else {
return NumericRangeQuery.newLongRange(
r.getField().getName(),
r.getMinTimestamp().getTime(),
r.getMaxTimestamp().getTime(),
true, true);
}
}
throw new QueryParseException("not a timestamp: " + p);
}
@SuppressWarnings("deprecation")
private Query notTimestamp(TimestampRangePredicate<ChangeData> r)
throws QueryParseException {
if (r.getMinTimestamp().getTime() == 0) {
return NumericRangeQuery.newIntRange(
r.getField().getName(),
toIndexTime(r.getMaxTimestamp()),
null,
true, true);
if (r.getField() == ChangeField.LEGACY_UPDATED) {
return NumericRangeQuery.newIntRange(
r.getField().getName(),
toIndexTimeInMinutes(r.getMaxTimestamp()),
null,
true, true);
} else {
return NumericRangeQuery.newLongRange(
r.getField().getName(),
r.getMaxTimestamp().getTime(),
null,
true, true);
}
}
throw new QueryParseException("cannot negate: " + r);
}
@@ -232,7 +250,7 @@ public class QueryBuilder {
return queryBuilder.createPhraseQuery(p.getField().getName(), p.getValue());
}
public static int toIndexTime(Date ts) {
public int toIndexTimeInMinutes(Date ts) {
return (int) (ts.getTime() / 60000);
}