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,128 | Comments: 45,550

filter by tags archive

Steamlining RavenDB, Part II - Why RavenDB Lazy Requests are in the Advanced section?

time to read 3 min | 434 words

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.


Frank Quednau

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?

Ayende Rahien

Frank, Usually, reporting scenarios are a good candidate to use a relational DB rather than a document one

Daniel Lang

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!

Ayende Rahien

cs, I'll try to add something about this to my queue for blogs.

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - 18 hours from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  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