Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,475

filter by tags archive

Awesome feature of the day, RavenDB Changes API

time to read 2 min | 358 words

This was a really hard feature. I’ll discuss exactly why and how in my next post, but for now, I pretty much want to gloat about this. We now have the ability to subscribe to events from the server on the client.

This opens up some really nice stories for complex apps, but for now, I want to show you what it does:


You can add subscribe to multiple documents (or even all documents) and you can also subscribe to changes in indexes as well.

Why is this an awesome feature? It opens up a lot of interesting stories.

For example, let us assume that the user is currently editing an order. You can use this feature to detect, at almost no cost, when someone have changed that order, saving the user frustration when / if he tries to save his changes and get a concurrency exception.

You can also use this to subscribe to a particular index and update in memory caches on update, so the data is kept in memory, and you don’t have to worry about your cache being stale, because you’ll be notified when it does and can act on this.

You can even use this to watch for documents of a particular type coming in and do something about that. For example, you might setup a subscription for all alerts, and whenever any part of the system writes a new alert, you will show that to the user.

The last one, by the way, is a planned feature for RavenDB Studio itself. As well as a few others that I’ll keep hidden for now Smile.


Jeff Doolittle

nice work. extremely compelling and extensively useful for a host of scenarios.

Matthew Bonig


Thomas Levesque

Very nice!

However the API seems redundant; I would change it to this:

store.Changes() .Document("orders/1293") .Subscribe(Reload);

Paul Stovell

This is awesome. I have a task queue implemented on top of RavenDB, and I have a timer polling the database every few seconds to check for new tasks. Being able to subscribe to new tasks would be amazing.

Will it work on embedded document stores?


Matthew Bonig

@Thomas: I think the syntax as is works well since it's not necessarily a document that you may subscribe to but in fact something wider. This leaves that distinction open.

Wilson Mead III

This is exactly what I was looking into a day or so ago. And since I saw signalR embedded in there, I was hoping that would be why.

Now to figure out how to get it to work on a web server :)


Kick ass feature!!

Ken Egozi

SignalR ftw

this can do wonders to cache invalidation.

btw these days if you had to re-implement ravenDB from the floor up, you might have had Storage+Subscription => feeding indexes ...

Daniel Lang

Amazing! Congratulations to this feature - it is really a game changer!

Ciarán O'Neill

This has a suspicious smell of SignalR to me :)

Ayende Rahien

Paul, Yes, it will work for embedded as well.

Ayende Rahien

Guys, This is actually NOT using SignalR. We tried using SignalR and couldn't make it (next post will discuss this in details). It is our own implementation.

Ken Egozi

lol who would have guessed :)

looking fw for a post on that.

btw the SignalR gang are just around the corner from my office. ping if you want to connect

Andrej Slivko

I have one question: can i subscribe to documents that is not yet created? My use case is - 1) I'm generating guid in browser, 2) I'm sending command to create new entity with that guid to web backend 3) Web backend then sends that command to aggregate, aggregate generate events 4) View builder (that is subscribed to those events) updates web view db (raven) 5) And here i would like raven to inform my web backend about updated views and from there i will get this info to browser by signalR.

This means that i have to subscribe to raven at step 3. At that step i will have new document guid and type, but doc still won't be in raven.


Congrats, Ayende! I get excited just by thinking how awesome is this. Having async notifications on everything on the database level - not client specific - is opening up a big number of user experience(among other) improvements one could make.

I actually thought about 6-7 ways to use this feature in just 5 minutes of thinking about it.

Good work, man!


Is this feature available already in nightly builds?

Ayende Rahien

Simone, It will be later today

Brian Vallelunga

Will there be any way to automatically tie this in with the aggressive caching? It would be great to be able to set a document to be aggressively cached until it is updated on the database.

Ayende Rahien

Sony, Define your app system user in ldap, yes.

Kele Turnipseed

Is that using IObservable from RX? Have you considered the queryable version (IQbservable)?

Ayende Rahien

Kele, It is using IObservable, yes. You are free to use RX on top of that too.


Ayende, what is your view on RX? In an a-sync env (in a key Silverlight app in our company) I noticed it can slice the complexity and source line count into half. Are you going to use it more ?

Ayende Rahien

Ed, I think RX is awesome, and yes, it does significantly reduces the code


I have downloaded the latest unstable build but I can't see the Changes method on the document store. Is it available already?


Ok sorted it out, the last unstable doesn't really seem to be the latest. Got the penultimate and it works. Nice feature!

Comment preview

Comments have been closed on this topic.


  1. The design of RavenDB 4.0: Making Lucene reliable - 16 minutes from now
  2. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - about one day from now
  3. The design of RavenDB 4.0: Physically segregating collections - 2 days from now
  4. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 3 days from now
  5. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 6 days from now

And 13 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    02 May 2016 - You want all the data, you can’t handle all the data
  2. The design of RavenDB 4.0 (13):
    28 Apr 2016 - The implications of the blittable format
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats