close RethinkDB changefeed перед изменением

Question

Кажется, я не могу найти информацию в документах rethinkdb о том, как вы могли бы остановить изменение, до того как будут произведены первые изменения. Вот проблема, что делает это необходимым:

клиент подключается к серверу через сокет, который начинается с changefeed, что-то вроде этого:

var changeCursors = {}; 
db('app').table('things').changes().run(cursor, function(err, cursor) { 
    // do something when changed 
    changeCursors[user.id] = cursor 
}) 

// later, when the user disconnects 
changeCursors[user.id].close() 

Когда первое изменение отправляется, я могу назначить курсор к переменной в памяти, и если клиент отключается, закройте этот курсор.

Однако, что, если пользователь отключается до первого изменения?

Насколько я могу судить, переосмысление не поддерживает отправку исходного состояния в канал, поэтому курсор будет доступен только после изменения. Однако, если пользователь отключается, changeCursors[user.id] не определен, а смена возвращается навсегда.

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

Есть ли способ получить курсор из смены без выполнения run обратного вызова? Альтернативно, есть ли способ заставить переосмыслить выполнение первоначального обновления состояния для обратного вызова run?

Answer 1

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

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

Я бы не стал беспокоиться об использовании памяти, если вы не уверены, что это проблема; если какая-то часть секунды проходит без изменения, мы возвращаем курсор без начальных значений клиенту, поэтому использование вашей памяти в случае большого количества пользователей, открывающих и немедленно закрывающих соединения, будет пропорционально количеству пользователей что в этой части секунды. Если эта часть секунды слишком длинная для вас, вы можете настроить ее на меньшую величину с помощью optargs до run (http://rethinkdb.com/api/javascript/run/). (Я бы просто установил firstBatchScaledownFactor, чтобы быть выше в вашем случае.)