1

I guess there is a delay between a record.set(...) call and a document is updated in DB. Note the document is finally updated in DB, but it doesn't happen immediately. I have acceptance tests that covers document updating flow and sometimes it passes as update is detected, sometimes it fails because of the time it checks the DB it has no changes yet. Even when test fails I can check DB manually and see document is updated. Test code uses direct connection to rethinkdb to check the updated document. I wonder if deepstream has actually a delay on record update and how I can tune it. Note that I have no cache like redis enabled for deepstream on test environment. To understand case better have a look at code snippets below.

Consider I have an rpc endpoint like:

   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' });
     })
   });

Test code looks like:

   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 is just my wrapper for rethinkdb library that simply gets or inserts data directly to the DB for test purposes.

Vasiliy Sadokhin
  • 87
  • 6

1 Answers1

2

There isn't a enforced delay on the record being set on the db, but a write to the database is not required to happen before notifying other clients that it has been updated, only to the cache. This helps keep message latency really low.

You can see the line that does that here.

Setting the record and then directly querying it from the database seems to be quite an odd combination, can you tell me more about your use case?

yasserf
  • 391
  • 1
  • 7
  • Hey Yasserf, thank you for your reply! That's not odd, I actually used this approach on many projects before with different technologies. Just a fact that server finished the call doesn't mean data correctly passed to DB. I also wanted to make acceptance tests less coupled to deepstream itself that gives us flexibility to change back-end technology keeping tests working. I solved the issue fetching data via deepstream client instead of working directly with DB. It doesn't sound nice but at least it works for now. – Vasiliy Sadokhin Mar 19 '16 at 03:31
  • Sorry I should have elaborated more, I meant it's odd because I expected the data to be fetched by the client directly when using records. I can see the usecase where you would want to run a query directly afterwards, I haven't personally run into it because I use rethinkDB changefeeds but is certainly something to keep in mind! – yasserf Mar 19 '16 at 17:47
  • Regarding tests, what you can do is access the cache used and make sure it's in there. The data is guaranteed to be written into the cache before notifying other clients so you should be able to access that immediately. – yasserf Mar 19 '16 at 17:53
  • Yeah, thank you Yasserf. I don't use any 3d party cache like redis or memcached on dev/test environment. So I simply reused deestream client to get proper record by id. The issue is that sometimes I don't know the id so I have to a) just wait using timeout before check DB directly b) modify my endpoint to return id only for test reasons (meaning front end side doesn't require the id in reply). – Vasiliy Sadokhin Mar 22 '16 at 10:26