My 10 tips and tricks with RavenDB

by Phil Jones

This knowledge base article aims to provide you with a list of tips and tricks that I have collected over my 8 months using RavenDB every day.

My 10 tips and tricks with RavenDB

I've been using RavenDB with my client Escape Trips (see my testimonial here) for 8 months so far and I've collected these 10 tips, tricks and hints over that time.

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 over Query 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 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() 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 this 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 puts it.

8. Null Lists

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

But initialise List'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



Here are a few blogs to read:

Ayende's Blog

Phillip Haydon's Blog

Gregor Suttie's Blog

There are 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 RavenDB mailing list (The RavenDB team monitors this)

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

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

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

Comments add new comment

The comments section is for user feedback or community content. If you seek assistance or have any questions, please post them at our support forums.

reply Posted by GregB on

In #7 above, you call out the fact that Index Maps don't define the shape of the result, which is a lesson I've just learned. It would be really useful if you could link to a document details how to shape those results, as it seems like the obvious thing to do.

Louis Ciavarella
reply Posted by Louis Ciavarella on

Are there any recovery tools for a corrupt RavenDB? Our ATX 2013 tax software will not open due to a corrupt database. We have lost a lot of our tax data and all of the backups made using Symantec Backup exec were done on a live database so the datastore will not open. Even though the database will not open is there a way to extract some of the data?

Craig Brett
reply Posted by Craig Brett on

In number 2, you say don't abstract out your unit tests and just use an embedded one. This is the approach I took as well. Might be worth mentioning the RunInUnreliableYetFastModeThatIsNotSuitableForProduction setting, as this seems to help.

However, have you experienced or heard of any issues with using an embedded DB for testing with tools such as NCrunch?