Jason Rowe

Be curious! Choose your own adventure.

Learning RavenDB from Raccoon Blog

I’m starting a new project that will require RavenDB. I’ve been to a user group which gave an overview of RavenDB and read some of the docs. Now I’m going to walk through the official sample project Raccoon Blog to learn more.

The first thing I’ll look for is how does the app expect RavenDB to be run. According to the docs and blog posts you have 4 options on how you can run the server. Hopefully the project gives some guidance on best practices for a production/development scenario.

Here are the 4 options to reiterate

  1. A console application that runs on your computer and listen to incoming HTTP requests. In order to use this option, just run the Raven.Server.exe from the Server folder or double click the Start.cmd script from the root directory. This is mostly suitable for debugging and experimentation.
  2. As a Windows Service, which you can install by executing “Raven.Server.exe /install” command.
  3. An IIS website that have the files under the Web directory in the root folder of the website. This option seems to be more suitable for production.
  4. You can run RavenDB in an embedded mode, which will run the database inside your client application process.

The first place to look is the connection string. How is the web app RaccoonBlog.Web going to talk to Raven. Turns out it has the following connection string


<connectionStrings>
	<add name="RavenDB" connectionString="Url=http://localhost:8080;Database=RaccoonBlog" />
</connectionStrings>

So to get the app running I’ll just use the console application because this looks like the default port configuration. I had assumed I would see an in-memory embedded instance when debugging. I figured this would be easier in a development scenario. Turns out they just have a very nice error page when the app can’t find RavenDB. I actually think this makes it simpler then trying to switch depending on the mode of use. I might have to rethink my idea of using the in-memory for development and just use that for unit testing and prototypes.

So what I’ll do is download RavenDB and click on the “Start.cmd”. That fired up the service and I can see it running. The manager also opened and I can see I only have one default database. So now I have RavenDB running on the correct port but I don’t have the actual database “RaccoonBlog” that the connection string is looking for. I’ll just try to run the app and see what happens. Not surprisingly, it automatically created the database for me. After refreshing the management page I see the new database and indexes. I believe this is all done via the following code in the global.asax.cs file


DocumentStore = new DocumentStore
			        {
			            ConnectionStringName = "RavenDB"
			        }.Initialize();

TryCreatingIndexesOrRedirectToErrorPage();

Now I’ll look for the setup and configuration of the blog to get some ideas about saving data and fetching data from RavenDB. The Raccoon blog has a Welcome page which lets you do all the configuration. I’ll take a look at how the controller is saving information and look at how the controller handles the db connection (DocumentStore), session(IDocumentSession), and actual save syntax.

I know from the documentation that the DocumentStore should be a singleton and the IDocumentSession should be per request. Looks like this is all handled via controller base classes. The DocumentStore is initialized in the Global.asax.cs with the following line of code:


RavenController.DocumentStore = DocumentStore;

Then per request the RavenController sets up the session using the following code:


public IDocumentSession RavenSession { get; set; }

protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
    RavenSession = (IDocumentSession)HttpContext.Items["CurrentRequestRavenSession"];
}

The important take away is that the IDocumentSession is created OnActionExecuting or per request and the DocumentStore is initialized on startup and used for all sessions. Here are the events that do all the actual work to populate the HttpContext and then save the results.


public MvcApplication()
{
    BeginRequest += (sender, args) =>
    {
        HttpContext.Current.Items["CurrentRequestRavenSession"] = 
                    RavenController.DocumentStore.OpenSession();
    };
    
    EndRequest += (sender, args) =>
    {
        using (var session = 
              (IDocumentSession)HttpContext.Current.Items["CurrentRequestRavenSession"])
        {
           if (session == null)
              return;

	   if (Server.GetLastError() != null)
	      return;

              session.SaveChanges();
	}
	      TaskExecutor.StartExecuting();
     };
}

Everything looks normal up until the TaskExecutor.StartExecuting() line. Looking at the code that just looks like an infrastructure component for saving comments and sending emails as background tasks. This is nothing RavenDB specific.

That’s all I’ll look at for now since it covers the important areas of getting started. Looks like from the connection string the console app is a good way to go for development. Also, The DocumentStore is definitely a singleton and the IDocumentSession are used per request. Next time I will start looking more closely at usages of the IDocumentSession throughout the project.


Posted

in

by

Tags:

Comments

One response to “Learning RavenDB from Raccoon Blog”

  1. Gustavo Avatar
    Gustavo

    Excelent post Jason. Very descriptive and usefull. I’m just learning RavenDb and didnt know where start or get serious examples.

Leave a Reply

Your email address will not be published. Required fields are marked *