+972 52-548-6969
Steamlining RavenDB, Part II - Why RavenDB Lazy Requests are in the Advanced section?
I really like notion of reducing the number of remote calls, so why did I stick the Lazy Requests feature of RavenDB in the session.Advanced section of the API and not put it in the center, directly off the session?
The answer is that I expect Lazy Requests to be a very powerful feature, but at the same time, it isn’t important enough a feature for us to justify increasing the surface area of the session. One of the main goals with RavenDB is simplicity and power. The simple stuff should be simple. We actually consider this a bug if you can’t pick up RavenDB and start using it in ten minutes or less.
That does not means that we don’t add powerful features, but we are careful in ensuring that those features won’t contaminate the Getting Started scenario.
Another consideration is that as powerful as Lazy Requests are, the common best practice for RavenDB is already reducing the number of requests drastically, so we mostly need them for occasional use, vs. common usage. One we figured that in many cases, using Lazy Requests is a rare thing, the decision where to put it became much simpler. In other words, it doesn’t really matter if you are making two queries vs. one. It matters a lot more if you are doing 30.
One of the more interesting aspects of designing RavenDB is actually in the exposed API. We are working hard to make sure that this API is as simple and predictable as possible. I am more than willing to give users options to solve specific problems, but it is important to consider that at its core, RavenDB is a database, and as such, what people mostly care about is CRUD. And that is why the session interface is the way it is, because you get to do CRUD right off the bat, and if you want more knobs to turn and handles to crank, you go to behind the session.Advanced door and can get all of the features that you could imagine.
Another aspect of that is the suggestions of API from users for all sort of stuff. From SaveChangesAndWaitForIndexing to DeleteAll, etc.
Those things are useful, sure. But they can be implemented as extension methods, and they wouldn’t be useful for the general case. The thing that I am trying to avoid is the case where you have something like what happened to Rhino Commons Repository<T>, which got so many features to handle one off use cases that it was really quite hard to use for the common case.
Comments
Here is a tangential question which I wanted to ask for a while. In what situations would you actually consider a RDBMS to be the better choice as opposed to using a Document Database? Since you are pushing the envelope on RavenDB, you may not be the best person to ask, but you've used NH + SQL in earnest, so maybe there are scenarios where you would choose e.g. SQLServer over a Document database?
Frank, Usually, reporting scenarios are a good candidate to use a relational DB rather than a document one
Ayende, I really like your choice of keeping the API very simple. Everything beyond CRUD should go directly to Session.Advanced or instead be implemented as an extensions method. That way it remains easy for new developers to understand existing code.
Keep on that great work!
In general terms what you expect when using the RavenDB API is what you get. That was my case except for DocumentQuery being mutable, which can be frustrating until you get to know it.
+1 for keeping it simple.
Ayende, can you expand on your answer to Frank's question? What other scenarios would you choose a RDBMS over RavenDB? I'm new to NOSQL, and I'm currently struggling with trying to figure out how to identify which scenarios Raven would be used instead of NH+SQL. Thanks!
cs, I'll try to add something about this to my queue for blogs.
Comment preview