+972 52-548-6969
Awesome feature of the day, RavenDB Changes API
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:
store.Changes()
.DocumentSubscription("orders/1293")
.Subscribe(Reload);
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 
.
Comments
nice work. extremely compelling and extensively useful for a host of scenarios.
http://suzumiyayuki.files.wordpress.com/2012/01/mind-blown.gif
Very nice!
However the API seems redundant; I would change it to this:
store.Changes() .Document("orders/1293") .Subscribe(Reload);
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?
Paul
@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.
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!!
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 ...
Amazing! Congratulations to this feature - it is really a game changer!
This has a suspicious smell of SignalR to me :)
Paul, Yes, it will work for embedded as well.
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.
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
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.
Andrej, Yes, you can
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?
Simone, It will be later today
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.
Brian, Yes
Sony, Define your app system user in ldap, yes.
Is that using IObservable from RX? Have you considered the queryable version (IQbservable)?
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 ?
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