Deepstream не обновляет документ rethinkdb сразу

Я предполагаю, что между вызовом record.set(...) и обновлением документа в БД есть задержка. Обратите внимание, что документ, наконец, обновляется в БД, но это происходит не сразу. У меня есть приемочные тесты, которые охватывают процесс обновления документа, и иногда он проходит, когда обнаруживается обновление, иногда он терпит неудачу из-за времени, когда он проверяет БД, в которой еще нет изменений. Даже когда тест не пройден, я могу проверить БД вручную и увидеть, что документ обновлен. Тестовый код использует прямое подключение к базе данных rethinkdb для проверки обновленного документа. Интересно, действительно ли у Deepstream есть задержка при обновлении записи и как я могу ее настроить. Обратите внимание, что у меня нет кеша, такого как Redis, включенного для глубокого потока в тестовой среде. Чтобы лучше понять регистр, взгляните на фрагменты кода ниже.

Предположим, у меня есть конечная точка rpc, например:

   ds.rpc.provide('update-document', function (data, response) {
     var record = ds.record.getRecord(`document/${data.id}`);
     record.whenReady(function () {
       user.set('field','value');
       response.send({ status: 'UPDATED' });
     })
   });

Код теста выглядит так:

   var document = {...}; // document properly created and saved in DB here 
   client.rpc.make('update-document', document, function (error, result) {
     // we hit successfully, so the call ended well
     assert.equal(result.status, 'UPDATED'); 
     rethinkDBService.get(`document/${document.id}`).then(function (documents) {
       assert.equal(documents.length, 1);
       var updatedDocument = documents[0]._d;        
       // problem here: sometimes it has "field" property with 'value'  
       // sometimes it doesn't  
       assert.equal(updatedDocument.field, 'value'); 
       done();
     })
     .catch(console.log)
   })

rethinkDBService — это всего лишь моя оболочка для библиотеки rethinkdb, которая просто получает или вставляет данные непосредственно в БД для целей тестирования.


person Vasiliy Sadokhin    schedule 18.03.2016    source источник


Ответы (1)


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

Вы можете увидеть строку, которая делает это здесь .

Установка записи, а затем прямой запрос к ней из базы данных кажется довольно странной комбинацией, можете ли вы рассказать мне больше о вашем случае использования?

person yasserf    schedule 18.03.2016
comment
Привет, Yasserf, спасибо за ответ! Это не странно, я действительно использовал этот подход во многих проектах с разными технологиями. Тот факт, что сервер завершил вызов, не означает, что данные правильно переданы в БД. Я также хотел сделать приемочные тесты менее связанными с самим Deepstream, что дало бы нам гибкость для изменения внутренних технологий, поддерживающих работу тестов. Я решил проблему с получением данных через клиент Deepstream вместо того, чтобы работать напрямую с БД. Звучит не очень хорошо, но, по крайней мере, пока работает. - person Vasiliy Sadokhin; 19.03.2016
comment
Извините, я должен был уточнить больше, я имел в виду, что это странно, потому что я ожидал, что данные будут извлекаться клиентом напрямую при использовании записей. Я вижу вариант использования, когда вы захотите запустить запрос сразу после этого, я лично не сталкивался с этим, потому что я использую каналы изменений rethinkDB, но, безусловно, об этом следует помнить! - person yasserf; 19.03.2016
comment
Что касается тестов, вы можете получить доступ к используемому кешу и убедиться, что он там. Данные гарантированно будут записаны в кеш перед уведомлением других клиентов, поэтому вы сможете получить к ним немедленный доступ. - person yasserf; 19.03.2016
comment
Да, спасибо, Яссерф. Я не использую сторонний кеш, такой как Redis или memcached, в среде разработки/тестирования. Поэтому я просто повторно использовал клиент deestream, чтобы получить правильную запись по идентификатору. Проблема в том, что иногда я не знаю идентификатор, поэтому я должен: а) просто подождать, используя тайм-аут, прежде чем проверять БД напрямую, б) изменить мою конечную точку, чтобы возвращать идентификатор только по причинам тестирования (это означает, что передняя часть не требует идентификатора в Ответить). - person Vasiliy Sadokhin; 22.03.2016