My 10 tips and tricks with RavenDB

RavenDB 27 April 2012 | 1 Comment

So, as part of my build up to my presentation at Skills Matter Progressive NoSQL Tutorials in London on the 9th to 11th May, I’m breaking down my presentation into a series of blog posts, also thinking this might have give me even more ideas! (Shameless plug over)

1. Don’t use the Repository pattern

This seems to be quite a common thing with people coming to RavenDB from Entity Framework or NHibernate environments.

I made the mistake of using the Repository pattern with RavenDB and spent many hours reworking my code to remove it.

The blog post linked below sums up perfectly the reasons NOT to use the Repository pattern.

2. Don’t abstract Raven for your unit tests.

This is something I’ve seen and been asked a lot about, “How do you Mock RavenDB in your tests?” they are totally shocked when I say “I don’t”.

Don’t be afraid to hit the “database”.I use the Embedded version for unit tests. Purists will argue these “unit tests” become “integration tests”. I’ve not been bothered by “slowness”.

3. Exclude RavenDB NuGet files from version control

I’d never heard of excluding NuGet package files when I started out using RavenDB and I wasn’t that worried as they were reasonably small. Several updates later I regretted that. RavenDB moves quickly and stable builds are every 4-6 weeks so my version control footprint started growing.

I’d highly recommend turning on the package excluding features of NuGet. (right click your solution in Visual Studio and click “Enable NuGet Package Restore” and NuGet will handle the rest, make sure to exclude the packages folder in your version control system of choice)

4. Use Load<T> over Query<T> when you know the documents Id

Seems obvious doesn’t it?

Coming from EF where your code uses FirstOrDefault() for example, you are tempted to use code like:

Query<T, TIndex>(x => x.Id == “foos/1″).First()

But this executes a Query against the index. RavenDB has the notion of Load<T> which fetches the document via a quicker/better approach.

Your code becomes:


5. Take(10000) is never a good idea

A popular topic I see on the RavenDB mailing list is people complaining that RavenDB won’t return them 10,000 documents in one go! By default, no Take() included in your query will return 128, and the maximum value RavenDB will obey by default is 1024. I use the word obey, as RavenDB will ignore your value if its above the default max value of 1024.

Frankly, if you were doing it in SQL Server (Yes I did), you are doing it wrong.

Use paging to fetch the documents in batches or consider if you really need all the documents back, perhaps you should be using an index to do the work?

6. Use Tenants, they’re not scary

For months I was putting all my data into the default database that RavenDB creates. I hadn’t bothered to investigate “tenants” as they sounded scary and complex.

If like me you are coming from SQL Server or MySQL land, a tenant just means a separate database. Using the default database is like sticking all your tables into the “master” database in SQL Server!

7. Map in indexes != results shape returned

In my early days of RavenDB, it’d really confuse me why the Map part of Map/Reduce didn’t effect the shape of the data returned.

In this thread I posted in my early days I finally learnt that:

Map is used to control _searches_, not shape the results.

As Ayende put it.

8. Null Lists

Something I’ve never really understood about C# is how you can have an: Null, Empty or Populated List<T> type.

But initialise List<T>’s in the constructor so you don’t have to implement nasty code to check for nulls when interacting with documents.

A bit annoying but a useful trick I’ve found in keeping the repetitive and annoying null handling logic to a minimum.

9. Read other peoples code, their blogs and watch TekPub/Pluralsight

A few good sample RavenDB projects to browse through and get ideas:

RavenDB source (duh)



Here are a few blogs to read:

Ayende (obviously, duh)

Phillip Haydon

Gregor Suttie

There are many more but those are in my bookmarks and Google Reader.

TekPub and Pluralsight both have courses on RavenDB that are nice and friendly. My biased opinion is I found the TekPub production more fun and also there is also an interesting Triage episode with Ayende.



10. Don’t be afraid to ask for help

There are plenty of people out there willing to help you learn. We all had to learn RavenDB and are willing to help!

The mailing list (The RavenDB team monitors this)

You can also use StackOverflow to ask questions using the RavenDB tag.

The Jabbr chat room (Us cool RavenDB kids hang out here offering help)

If you tweet with the hashtag #RavenDB or mention @RavenDB you’ll probably get a response too.

11. SQL Server dread

Be careful. Ayende has made RavenDB to be highly addictive and once you start using it, you’re hooked. SQL Server and Entity Framework will fill you with sadness.

Well, maybe not that much but you’ll start seeing some of the problems with SQL Server and Entity Framework you’d have just ploughed through or ignored.

I’ve got a funny story involving a job interview and RavenDB that I’ll only share over beers.

One Response on “My 10 tips and tricks with RavenDB”

  1. Mourad says:

    When I use the Sample Data that has a namespace of MVCMusicStore and I call the data as Load( 123 ) it retnrus nothing. If I use Load( albums/123 ) it works. Is this to do with namespaces at all because my little app is not the same namespace?Is it just my RDBMS brain taking over or should I not be able to use the former to find the album?

Leave a Reply