Skip to content

Revert using objectId as tie breaker in infinite scrolling #1799

Closed
@mtrezza

Description

@mtrezza

New Issue Checklist

Issue Description

Since #1706, creating an index to optimize dashboard queries requires compound indices including objectId. For example, when browsing a class sorted by createdAt a compound index createdAt, objectId is required.

if (field !== 'objectId') {
if (sortDir === '-') {
query.addDescending('objectId');
} else {
query.addAscending('objectId');
}
}

This approach requires special indices just for dashboard browsing. If an app is using a complex or resource intensive index, dashboard requires the same index plus the additional objectId in the index compound. I don't think this is a feasible solution, given the high cost of indices on a DB. Maybe we need to look for an alternative solution.

Additionally, #1706 broke existing "query optimization" and should have been treated as a breaking change. The reason this was released as non-breaking was that we didn't have the policy that a changelog entry has to be written as part of the PR back then. It was not noticeable without reading the PR discussion in detail that it was a breaking change. This should not happen anymore as we are now requiring a changelog entry with the PR.

Steps to reproduce

  1. Create new call
  2. Browse class, sorted by createdAt
  3. Query createdAt, objectId sent to server

Actual Outcome

Dashboard currently paginates by issuing an entirely new query which requires to construct a complicated pagination mechanism (#1706), which creates the indexing issue described here.

Expected Outcome

In MongoDB at least, the proper and resource efficient way to paginate is to use the query cursor, see getMore. That may require some changes on the server side, for example sending the cursor ID to dashboard as query results meta data. And not sure whether Postgres supports cursor based pagination.

In any case, I think we should revert #1706 ASAP and release as a fix, or at least the part that adds the object ID to the query, because that can render the dashboard unusable or cause stability issues for some deployments.

@sadakchap @davimacedo @Klaitos What do you think?

Environment

n/a

Dashboard

  • Parse Dashboard version: 2.2.0, master

Logs

n/a

Metadata

Metadata

Assignees

No one assigned

    Labels

    type:bugImpaired feature or lacking behavior that is likely assumed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions