86caf9ec23
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 |
||
---|---|---|
.. | ||
src | ||
BUCK |