через курсоры.
Базовое решение основано на LIMIT/OFFSET.
Плюсы:
- Можно указывать сторону сортировку (DESC/ASC) на конкретную колонку.
Минусы:
- Данные при смещении могут повторяться
Реализация на Primary Key/Timestamp
Плюсы:
- Объекты не будут повторятся
- Курсор остаётся актуальным длительное время
Минусы:
- Невозможно использовать сортировку по колонке не являющиеся ключом (PK/Timestamp)
Конечно понимаю что второй вариант используют в основном в какой-нибудь ленте или списке сообщений. Мне второй вариант нравится больше, но минус перекрывает плюсы.
Так какой будет эталонный вариант реализации будет? Может я чего не учёл.
Релеевские курсоры - хорошая спека: https://facebook.github.io/relay/graphql/connections.htm . Реализовать можно сортировку по любьым УНИКАЛЬНЫМ полю/полям. Тут чутка инфы, почему нужны уникальные поля для курсора https://github.com/graphql-compose/graphql-compose-connection/issues/33 В этой же репко можно посмотреть реализацию этой спеки. Суть работы: - вы сортируете свой коннекш по какому-то уникальному полю или набору уникальных полей. К примеру захотели сортировать по дате создания и айдишнику (кардиналить даты создания тупо не хватает, т.к. может быть создано много записей в одну секунду. Поэтому еще к дате надо приклеить ID, чтоб реально получать уникальные курсоры): sort: CREATED_AT_AND_ID_DESC - далее когда возвращаете результаты, для каждой записи в курсор вы должны положить значения согласно той сортировки, которую использовалась в запросе(в моем примере `base64({ createAt: ‘2020-01-12 10:03:15’, id: 1745 })`) - когда вы хотите получить следующую порцию данных в коннекшене, вы графкуэль запросе должны передать КУРСОР и ту же СОРТИРОВКУ: cursor: base64({ createAt: ‘2020-01-12 10:03:15’, id: 1745 }), sort: CREATED_AT_AND_ID_DESC - на стороне сервера когда поймали курсок должны правильно сконструировать запрос в базу согласно КУРСОРА и СОРТИРОВКИ, в моем случае WHERE createdAt <= ‘2020-01-12 10:03:15’ AND id < 1745 ORDER BY createdAt DESC, id DESC
Обсуждают сегодня