Повторное использование Meteor Observer: изменение моего запроса возврата публикации, чтобы не использовать this.userId, сделает мой наблюдатель более пригодным для повторного использования?

У меня есть публикация, которая возвращает курсор, который выглядит так:

// Publication RETURNS THIS QUERY

Notepads.find({_id: notepadId, $or: [{userId: this.userId}, {'collaborators.userId': this.userId}], archived: false})

Как видите, запрос уникален для пользователя, поскольку включает this.userId

Я использую this.userId в публикации как форму безопасности. Вы получите данные, только если вы связаны с этим конкретным блокнотом.

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

// Optimized publication

notepad = Notepads.findOne({_id: notepadId, $or: [{userId: @userId}, {'collaborators.userId': @userId}], archived: false})

if notepad?
  // Optimized publication RETURNS THIS QUERY 
  return Notepads.find({_id: notepad._id, archived: false})
else
  return

Я думаю, это то, что означает повторное использование наблюдателя. Что публикация возвращает один и тот же запрос для любого подписавшегося на нее пользователя. Так ли это правильно, стоит ли менять эту оптимизацию?


meteor meteor-publications
person Nearpoint    schedule 17.11.2016    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Проблема с вашей оптимизированной версией: она не реактивна. Поскольку вы используете Notepads.findOne в качестве проверки безопасности, чтобы убедиться, что у пользователя есть доступ к документу.

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

person kkkkkkk    schedule 18.11.2016

arrow_upward
0
arrow_downward

Цитата из kadira.io о том, как обращаются с наблюдателями в Метеоре:

Чтобы создать идентичных наблюдателей, вам нужно создать курсоры с помощью:

  • та же коллекция
  • тот же селектор (запрос)
  • тот же набор опций (включая сортировку, ограничение и т.д.)

В вашем примере селектор не одинаков для разных пользователей.

Селекторы – это литералы объектов, которые оцениваются до передается в вызов .find. Это означает, что {_id: notepad._id, archived: false} становится

  • {_id: 'myNotebookID', archived: false}, or
  • {_id: 'anotherNotebookId', archived: false}.

Как видите, это разные селекторы после разрешения notepad._id, и это происходит до того, как они будут переданы в .find().

Если бы ваш первый запрос к БД вернул тот же блокнот, потому что ваш второй пользователь был соавтором блокнота первого пользователя, вы бы получили тот же селектор и один курсор / наблюдаемый. Однако для большинства приложений это вряд ли будет достаточно распространенным явлением для оптимизации, тем более что (как указывает @Khang) вы потеряете реактивность.

Итак, это не тот же запрос, он не будет повторно использовать наблюдателя и не стоит изменений.

person JeremyK    schedule 18.11.2016
comment
Здравствуй. Я сбит с толку. Не могли бы вы еще раз взглянуть на оптимизированный запрос, который я сделал. Я сделал именно так, как ты сказал. Если сначала найти блокнот, то я возвращаю курсор return Notepads.find({_id: notepad._id, archived: false}) Это изменение, которое я сделал - person Nearpoint; 18.11.2016
comment
спасибо за подробный ответ! Это хороший материал. Но я хочу прояснить один момент. Если многие пользователи работают над одним блокнотом (один и тот же notepad._id), не поможет ли это изменение? Что касается реактивности, код настроен так, что пользователь будет подписываться только после того, как станет соавтором. И если их удалить как соавторов, пока они в блокноте, то все равно будет синхронизировать блокнот, а на клиенте я могу смотреть блокнот и прекращать подписку, если они больше не коллаборируют. Итак, учитывая эти случаи, стоит ли сейчас менять? - person Nearpoint; 18.11.2016
comment
Я думаю, стоит ли оптимизировать, скажем, типичное сотрудничество в блокноте между 5 пользователями? 10 пользователей? 40 пользователей? Думаю, я бы предпочел не проводить оптимизацию, если это почти ничего не меняет, и я теряю реактивность. - person Nearpoint; 18.11.2016
comment
Не гадайте и не оптимизируйте, пока не поймете, что это необходимо! - person JeremyK; 18.11.2016