RavenDB-Image Gallery Project (II) - Setting Up

Published on 2010-9-28

As with all entries in this series, the up to date code  and history can be found in Github at http://github.com/robashton/RavenGallery/

Where do I get RavenDB?

RavenDB can be downloaded from a number of places, you can download the stable binaries, the unstable binaries or go direct to Github and use whatever fork you find there.

I personally run off my own fork which is updated very frequently from Ayende’s code – as it means I can rapidly add any missing features and push them back or fix bugs when I find them.

For this project I’ll be doing just that, and the binaries found in the Image Gallery project will be from my fork found at http://github.com/robashton/Ravendb

This is because I’ll be utilising functionality that is on the bleeding edge of RavenDB, of course by the time most of you read this they’ll be in the released binaries, so we’ll move to those now.

Released builds (Unstable)

Next up on the stability list are the recent builds, which can be found on the Hibernating Rhinos site http://builds.hibernatingrhinos.com/builds/RavenDB-Unstable, this is probably safer than constantly pulling from Ayende’s fork and represent the latest changes that have made it through code review.

Released builds (Commercial)

At time of writing, these are about 20 builds behind the Unstable branch, and as such miss out on some of the functionality that can be enjoyed in the Unstable and code versions of RavenDB. Unless you are planning on releasing software in the next week or two, I don’t really advocate using this branch for development.

Why unstable?

RavenDB is changing constantly, breaking changes still happen, API changes still happen, functionality is being added constantly – I have a suite of tests for all my projects that utilise RavenDB and I test all of my interaction with RavenDB.

By updating regularly I ensure that the amount of work needed to fix any breaking changes is kept to a minimum, as opposed to waiting 30 builds and finding out that half of my entire test suite fails.

That’s not to say that Raven isn’t ready for production because I believe that the stable branch is indeed stable, but because I’m in development and I haven’t got imminent release to look forward to I’m happy to put up with a few bugs in order to get the latest and greatest functionality.

The Project itself

Here is my solution

solution

And this is what I meant by setting the .NET profile

targetframework

 

Which RavenDB Binaries to use?

Once you’ve selected which binary drop to use, you have to make a decision as to which Raven.Client to use, and this is where I tell you why I made sure my Target Framework was set to 4

As my choice of target framework will tell you, I have chosen to host RavenDB internally as part of the web application, and I will take the responsibility for starting up and shutting it down as part of the application lifecycle.

The .NET Framework 4 profile is important, as it is a common gotcha for people to link the wrong binaries and wonder why they are still getting reference errors.

That’s set-up covered, in the next entry I shall cover how we’ll be hosting RavenDB in the application and managing our sessions with it.

Why not hire me?

I am available for emergency consults, workshops, training and short-term development work anywhere in Europe

C#, JavaScript, Clojure, RavenDB, NodeJS, Architecture review.. etc

Get in touch

blog comments powered by Disqus

KevDog


Rob,Extremely glad you're doing this series, some of your early posts on RavenDB were crucial in helping me get going.I don't know what your plans are for the entire series, but the biggest hurdle I am dealing with is adjusting my thinking toward modeling, so if I may be so bold as to ask for a LOT of detail on how you approach your class structure.Again, many thanks for doing this series.

Rob Ashton


I'm afraid there is no silver bullet to the problem of modelling, but hopefully the way I am approaching the problem will help with the way you think about the problem.I'll be building the class structure slowly, and going back and modifying the class structure as new requirements and features drive those changes.I aim to make this a good long series with plenty of revisiting and extra functionality/modifications - and feedback such as this will be helpful going forward for what to focus on

Derek


Good stuff, I was checking out the code. Cool idea of creating Documents separate from the Model, I didn't think of that.Also, how do your Dynamic queries work as far as stale results? Before, I was creating a dummy document with my userid so I could make sure it was unique. I see you're doing that with a dynamic query or with the DoesUserExistWithUsername in the UserService.

Rob Ashton


I'll be covering that later, but essentially dynamic indexes will wait until they either find the number of results or the index is non-stale.That's neither here nor there though, if the results *do* happen to be stale, the worst that can happen is I try to create the user document and it fails by throwing an exception (transaction fails, nothing happens)It's no different to SELECT COUNT(*) FROM users WHERE username = 'whatever';and thenINSERT INTO users { etc }Only to find that the unique constraint on username prevents the transaction from closing

Rob Ashton


I am not convinced about creating the model around the documents, I'll hold my breath to see how well it works out :)Trying it out rather than saying "this is how it should be", public humiliation followed by change is better than saying nothing at all!

Derek


It will be interesting to see how it works. It makes sense I guess, if impedance still exists even if it's a lot less than a relational database.