Как сделать запрос среди двух полей в FireStore? - PullRequest
1 голос
/ 17 октября 2019

Предположим, у меня есть коллекция Events, в которой есть startTimestamp и endTimestamp, указывающие, когда событие начинается, заканчивается соответственно.

Как запросить в firestore, чтобы узнать, является ли Событие живым / законченным / предстоящим?

Ответы [ 2 ]

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

Если свойства startTimestamp и endTimestamp существуют в базе данных и имеют тип Date и , а не String или Number, то вы можете просто использовать запрос, чтобы проверить, является ли конкретная датав пределах границ или нет.

Например, в Android, если вы хотите проверить, находится ли определенная дата в пределах границ, вы можете подумать, что запрос, подобный приведенному ниже, будет работать:

eventsRef.whereGreaterThanOrEqualTo("startTimestamp", yourDate)
    .whereLessThanOrEqualTo("endTimestamp", yourDate);

Но это не так. Вы получите исключение со следующим сообщением:

Все, где фильтры, кроме whereEqualTo (), должны находиться в одном поле. Но у вас есть фильтры для 'startTimestamp' и 'endTimestamp'

Единственное решение, которое у вас есть, - это создать три отдельных запроса.

Редактировать:

Согласно вашему комментарию, один запрос должен проверить, является ли ваш yourDate раньше startTimestamp

eventsRef.whereLessThanOrEqualTo("startTimestamp", yourDate);

Если это так, это означает, что это наступающее событие.

Вторым было бы посмотреть, не терется ли оно больше, чем startTimestamp:

eventsRef.whereGreaterThanOrEqualTo("startTimestamp", yourDate);

Где у нас есть два случая. В одном случае вы выполняете новый (третий) запрос, чтобы проверить, являются ли данные меньше endTimestamp:

eventsRef.whereLessThanOrEqualTo("endTimestamp", yourDate);

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

Чтобы получить эти данные в режиме реального времени, вы должны использовать прослушиватель снимка для каждого запроса.

0 голосов
/ 22 октября 2019

Вот случаи, чтобы справиться с этим сценарием. Я почти уверен, что это очень распространенная проблема, но нигде не нашел эффективных решений для этого.

Решение 1 : Соберите все документы в одну коллекцию с именем subscribedEvents. Как предположил Алекс,Нам нужно сделать для следующего статуса.

Предстоящее : currentTimestamp

Завершено : currentTimestamp> endTimestamp

Live : currentTimestamp>startTimestamp в первом запросе и currentTimestamp

Проблема: у меня может быть много документов (около 10 000) в подписанном времени и условие Live не масштабируется, так как я не могу ограничить результаты при запросах. Поскольку он должен пересекаться с двумя запросами, мне нужно выполнить запрос без фильтров.

Решение 2 : Это немного взломано, но масштабируемо. Не иметь все документы в одной подгруппе. Отделите предстоящие события и поместите эти документы в подписанную коллекцию событий / других / предстоящих.

Когда пользователь подписывается, если это наступающее событие, вы можете напрямую сохранить его в коллекции подписанных событий / других / Предстоящих.

Остальные документы могут быть отправлены непосредственно в коллекцию подписанных событий.

Предстоящие : запрос всех документов с помощью фильтра пределов из подписанных событий / других / Предстоящей коллекции.

Завершено : currentTimestamp> endTimestamp

Live : currentTimestamp

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

Теперь для этого шага требуется дополнительно задание cron, чтобы убедиться, что предстоящие события из предстоящей подгруппы перемещены обратно в subsppedEvents. .

Однако, если у вас меньше документов, решение 1 - этоидти. Но не в моем случае.

Надеюсь, это поможет кому-то, где они должны эффективно масштабироваться.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...