Проблемы с указателем и хранилищем запросов в хранилище данных ndb - PullRequest
Новая
       10

Проблемы с указателем и хранилищем запросов в хранилище данных ndb

2 голосов
/ 13 октября 2019

Мы используем ndb Datastore, python, стандартный движок приложений Google. Мы хотели бы использовать Query Cursor. Но чтобы это работало в соответствии с здесь и здесь , похоже, нам нужно реализовать datastore_model.query (). Order (-datastore_model.key).

Например, в нашем запросе у нас есть 

teacher_model_query     = teacher_model.query(ndb.AND(
                ndb.GenericProperty('signinout_time') >= signinout_time_start, 
                ndb.GenericProperty('signinout_time') <= signinout_time_end))

teacher_query_forward = teacher_query.order(ndb.GenericProperty('signinout_time')).order(teacher__model.key)
teacher_query_reverse = teacher_query.order(-ndb.GenericProperty('signinout_time')).order(- 
 teacher__model.key)

К сожалению, это означает, что мы должны создать новый индекс для этого 

- kind: teacher_model
  properties:
  - name: signinout_time
    direction: desc
  - name: __key__
    direction: desc

Это приводит к 200 индексамлимит на проект. Не могли бы вы подтвердить, что нам нужен заказ (-datastore.model.key), чтобы курсор запроса работал в обратном направлении? Как мы можем выполнить курсор Query без необходимости создавать дополнительные индексы?

Ответы [ 2 ]

2 голосов
/ 13 октября 2019

Вам нужно создавать такой индекс только в том случае, если вашему приложению требуется возможность перемещаться назад на страницах результатов запроса. Это может быть желательно, например, если вы предлагаете функциональность навигации по страницам и разрешаете такую ​​навигацию на предыдущую страницу.

Но такая функциональность обычно не требуется, если вы используете курсоры просто для разделения нагрузки обработки на меньшие партии- в таких случаях вы перемещаетесь только в одном направлении.

1 голос
/ 14 октября 2019

Изменение моего предыдущего поста, так как оно было совершенно неверным.

Согласно https://cloud.google.com/datastore/docs/concepts/queries#limitations_of_cursors

Исключением является случай, когда конечный порядок сортировки исходного запроса был на __key__. В этом случае вы можете использовать курсор в обратном запросе, который является исходным запросом с каждым обратным порядком сортировки. Обратный запрос может изменить начальный курсор, конечный курсор, смещение и лимит.

Таким образом, похоже, что последнее поле сортировки должно быть ключом И требуется другой индекс со всеми обращенными типами. Это потребует двух составных индексов.

Один из способов избежать этого, который я могу придумать, - хранить все курсоры в виде стека во время пагинации. Это может быть сделано на стороне клиента. Затем, когда пользователь перемещается назад или переходит на определенную предыдущую страницу, соответствующий курсор может использоваться для всегда движения вперед. Скажем, у вас есть размер страницы 25. Тогда вы бы создали курсор на 25, 50, 75 и 100. Затем, если пользователь хочет вернуться к 50, вы должны выбрать связанный курсор и сгенерировать строки от 50 до 75, которыевыполняет итерацию только вперед.

...