This project is read-only.

Experimental: RavenDB

Topics: General
May 19, 2011 at 2:30 PM

I couldn't find anything about RavenDB being implimented, but in the source code i noticed it.

Could the team share some idea's behind the open source document database "RavenDB" ?
Is it going to be the core for documentlike content (media, photo's, etc) or going to hold the dynamic fields xml data?

I just wonder why :)

May 19, 2011 at 8:34 PM

Ah, well.

We're playing around, experimenting. RavenDB is an interesting beast for a CMS such as Orchard because the storage model feels just right. There is a lot of dissonance and abstractions that we might be able to completely do without if we were relying on something like this for storage instead of a relational DB. But still, this is just experimental and not too much should be inferred from these experimentations.

May 19, 2011 at 8:52 PM

As Bertrand said...

Quick questions for the community here: Has anybody used RavenDB before? What's your take on the fit with a CMS like Orchard? Any other comments/suggestions?

May 19, 2011 at 11:28 PM

If NOSQL is read as Not Only SQL then I really like the idea of having a flexible data store that does a better job of storing documents and semantic markup as well as traditional data that SQL does so well.

I have looked at, but not actually used, Raven DB and I definately believe it has some excellent features to recommend it.

Another .Net based CMS with a non-SQL data store that is worth looking at for the purpose of learning is webnodes ( ). If you watch the 10 minute video accessable by clicking on the lizzard on the homepage you will get a good feel for their database. The beauty of their implimentation is that a non-programmer can impliment a new taxonimy without knowing much, if anything, about how the database is implimented; no DBA required ;-)

Their database is (in their words) a "Semantic Content Engine" ( ) and accessable via OData.

Incidently whatever Orchard uses for storage, now or in the future, OData support would be a valuable feature that (hopefully) would not be too difficult to impliment.

May 21, 2011 at 11:42 PM

@rpaquay like Bertrand said, such a fit is quite natural.

There's an official RavenDB sample blog application at

May 22, 2011 at 4:22 AM

@bertrandleroy @rpaquay  I've been evaluating RavenDB for my org's large internal system, and I have to say I'm extremely impressed.  There is obviously a lot of competition in the NoSQL space, and I believe that RavenDB competes very well with the other widely popular NoSQL DB's.

As for if it's a fit for Orchard, I would also have to say that it seems like it would be an extremely natural fit.  It just seems when we develop applications that are customizable/extensible (especially a CMS system), developers squeeze relational databases around in ways that they really are not ideal.

The RavenDB client API is artfully designed.  It has been a breeze to work with, and it *just works*.  It has caching 100% fully built in, and turned on by default.  One feature that particularly blows me away is the fact that the RavenDB server will automatically create indexes based on queries you make frequently - which esentially makes it "self optimizing".

May 23, 2011 at 10:42 PM

I implemented the (probably obsolete) admin UI for RavenDB, and used it quite extensively for portions of a large site.  It worked phenomenally, and was super fast.  My only complaints were limitations/quirks with the LINQ provider, and I think a large number of those have been addressed.

That said, I would love to have the *option* to use RavenDB, however I would think that the fact that it is a commercial (read: not free) product for anything other than an open source site would rule it out for anything other than an additional storage engine.  

May 24, 2011 at 1:37 AM
ldhertert wrote:

That said, I would love to have the *option* to use RavenDB, however I would think that the fact that it is a commercial (read: not free) product for anything other than an open source site would rule it out for anything other than an additional storage engine.  

Even though I'm very intrigued about RavenDB,  I too agree that RavenDB's license is not ideal for Orchard.

May 27, 2011 at 8:20 AM

Just to point out, since Orchard is OSS, there is no requirement to pay for RavenDB, and no issues in using it.

May 27, 2011 at 10:05 AM

Although, looking at the licensing page on the RavenDB website, it would mean that if anyone wanted to use Orchard in a commercial project, they would then technically have to pay for the commercial RavenDB license.

May 27, 2011 at 4:24 PM

Yeah Pete, that was what I was getting at.

May 27, 2011 at 4:25 PM

I do, however, think that getting the data access abstracted enough to support RavenDB would be hugely beneficial, if only for the fact that it should make it much easier to implement other storage solutions.

May 27, 2011 at 10:35 PM

It would be so cool to have Orchard storage more abstract and unbound from NHibernate (or SQL DBs in general). I agree that if plugging-in RavenDB would be a success that would mean we have a really abstract data access system. Pluggable system allowing plugging-in RavenDB, MongoDB, custom WCF-based data layer... Mmm, yummy!:)

May 27, 2011 at 10:43 PM

Well, abstraction can be expensive and constraining, especially when dealing with DB interaction. Then again, there is already a fair amount of abstraction and nHib doesn't surface that much. Do you have a specific example in mind where it gets in the way?

May 27, 2011 at 11:56 PM

Yes, too much abstraction is not good either. These were only my loose thoughts:) I was wondering if it would be possible to add some extension points that would make attaching different storage mechanisms easier and SQL-unbound. I know that it would involve adding some kind of abstraction, but maybe it could be thin enough not to affect performance much. Just something to get rid of direct relationship with SQL. I remember couple of months ago I tried to find a way to implement MongoDB storage. I bumbed into a wall when realised that building a db scheme in Orchard is tightly coupled with SQL concepts and requires to build DDL queries as a result. Just feeling that it could be easily decoupled by a class-thin abstraction layer (db driver interfaces) - something that would be put between Orchard repositories and NHibernate (and also between scheme builder and DDL generation).