RavenDB 4.0Data subscriptions, Part I

time to read 3 min | 516 words

imageI’ll be talking about this feature more once the UI for it is complete, but this feature just landed in our v4.0 branch and it is so awesome that I can’t help talking about it right away.

In RavenDB 4.0 we have taken the idea of subscriptions and pushed it up a few notches. Data subscriptions gives you a reliable push based method to get documents from RavenDB. You setup a subscriptions, and then you open it and RavenDB will stream to you all the documents that are relevant to your subscription. New documents will be sent immediately, and failures are handled and retried automatically. Subscriptions are a great way to build all sort of background jobs.

In RavenDB 3.x their main strength was that they gave you a reliable push base stream of documents, but in RavenDB 4.0, we decided that we want more. Let us take it in stages, here is the most basic subscription usage I can think of:

This is subscribing to all User documents, and RavenDB will first go through all the User documents, sending them to us, and then keep the connection alive and send us the document whenever a User document is updated. Note that we aren’t talking about just a one time thing. If I modify a document once an hour, I’ll be getting a notification on each change. That allows us to do hook this up to jobs, analytics, etc.

The really fun thing here is that this is resilient to failure. If the client maintaining the subscription goes down, it can reconnect and resume from where it left off. Or another client can take over the subscription and continue processing the documents. In RavenDB 4.0, we now also have high availability subscriptions. That means that if a server goes down, the client will simply reconnect to a sibling node and continue operating normally, with no interruption in service.

But you aren’t limited to just blinding getting all the documents in a collection. You can apply a filter, like so:

In this manner, we’ll now only get notified about active users, not all of them. This filtering allows you to handle some really complex scenarios. If you want to apply logic to the stream of changed documents, you can, getting back only the documents that match whatever logic you have in your document.

But the script can do more than just filter, it can also transform. Let us say that we want to get all the active users, but we don’t need the full document (which may be pretty big), we just want a few fields from it.

In this manner, you can select just the right documents, and just the right values you need from the document and process them in your subscription code.

There is actually more, which I’ll post in the next post, but I’m so excited about this feature that I’m not even going to wait for the next publishing schedule and push this immediately. You can read it here.

More posts in "RavenDB 4.0" series:

  1. (13 Oct 2017) Interlocked distributed operations
  2. (12 Oct 2017) Node.JS client is now in beta
  3. (11 Sep 2017) Support options
  4. (14 Aug 2017) Maintaining transaction boundary integrity in a distributed cluster
  5. (03 Aug 2017) Raven Query Language
  6. (13 Jul 2017) The admin’s backdoor is piping hot
  7. (10 Jul 2017) Securing the keys to the kingdom
  8. (04 Jul 2017) Unbounded results sets
  9. (13 Jun 2017) The etag simplification
  10. (12 Jun 2017) Data subscriptions, Part II
  11. (09 Jun 2017) Data subscriptions, Part I
  12. (19 May 2017) Managing encrypted databases
  13. (11 May 2017) Working with attachments
  14. (10 May 2017) Attachments
  15. (08 May 2017) Full database encryption