While browsing to look for a good alternative to Perst, I stumbled upon RavenDB, a document database for .NET. Be aware that this is written for .NET, not compatible with .NET. I think I should recall here why I felt to code a new CMS and why other tens of systems which are already available weren't good to implement new website (and web applications) for my company.

So here's a short rationale for Diavolo:

• I wanted to find new paths and attempt to create a new design: most of existing CMSes for .NET have been developed in .NET 2.0 era (and some even during 1.1 era!) so they have their roots in older framework versions and one can understand they can be very slow in keeping up with framework innovations. In many cases, things were difficult or not ideal in .NET 2.0 or 1.1 world while later versions brought many improvements and in many areas exisiting system duplicate framework functionalities;
• I wanted to explore a different approach to storage, expecially in database field. I started from willing to ensure broad compatibility by using some abstract library than I fell in love with the idea of getting rid of SQL at all and employ some Web 2.0 technology for that, expecially when such technology could ensure a better integration with code like using plain old .NET objects for maximum flexibility;
• I wanted to design Diavolo around lots of modern .NET technologies like workflows, transactional file-system, MEF or a very nice plugin system and so on. I wanted such things to be present since the beginning and incorporate most .NET framework innovations which came up with .NET 3.5 and 4.0 and I wanted to stay compatible with other great features .NET has to offer (authentication, theming and so on);
• I want my solution to be compatible with standard shared-hosting and then being scalable to dedicated servers or VM. However, being compatible with shared hosting is a must to ensure broad usage and that limited a lot my options for storage since I needed to choose either a broad-available solution (like SQL Server or MySQL) or an embedded solution (like Perst or VistaDB);
• of course, I want to be able to control this platform in order to serve my own (and my company's) interest in order to be able to reverse choices which looked wrong. Still, I want this platform to be open-source because I used a lot of OSS and I felt pushed to give something back, if it proved worth.

Storage problem was particularly difficult because I needed to choose something modern and cool but my requirement to stay compatible with most shared-hosting offers was a limitation. What if I choose to run Matisse ? That would be cool but how many people could do that ? Not so many and that would affect broad usage. So my options were limited to three possibilities:

• widespread used storage systems like SQL Server or MySQL, but that would have meant to be forced to keep SQL;
• XML, but we know how much difficult is to stay scalable with it;
• embedded database, something you could move to your shared hosting without requiring them to install anything;
• it should have been something native to .NET, not a conversion or something compatible with .NET.

Going embedded was most suitable option, though my first attempt was to use XML in order to try to stay compatible with medium-trust shared hosting offers, if possible. When that choice proved difficult, I decided to switch to embedded but wanted to find something modern, very easy to use but enough perfomant and possibly scalable. Embedded option allows you to be creative and I tried to be very creative, looking for database objects. There are a few, available for .NET, but many of them are high-end solutions, not only requiring to use external servers (bad choice, would constrain usage) but also requiring high licensing costs. In a vertical market application, that makes sense but my app was meant to be aimed at general usage. A few of them were embeddable and open source, a good mix for my goal. A solution like Perst could easily hold millions of objects so that looked the best choice. Unfortunately, embedded solutions are mostly aimed to embedded market, as I explained in my previous post.

Once I decided to scrap Perst, my wish was to find an alternative which was as handy as that, just more optimized for Web apps. I already knew about document databases and a friend was very excited about MongoDB so I decided to try to look for document databases for .NET. To be honest,  the whole document-database concept seemed a subclass of a generic objects database to me so my primary choice was an objects-database and I wasn't very confident to be able to find something suitable for my goal. I was very close to revert my decision about storage and bring it back to classic SQL when I found RavenDB and a few of its features excited my mind:

• as a start, server requires .NET 4.0 so it's really up-to-date;
• it is aimed to a new, more modern concept than RDBMS when dealing with databases and storage;
• it was designed for Web 2.0 so its goal was to solve THAT kind of problems I had (unlike Perst... see my previous post);
• ensures a clear evolution path since you can switch from embedded to Web application to standalone server in a very easy way;
• it is RESTful and while I seem not to be excited about AJAX as much as many others are, that really cannot hurt and could prove useful at a later time;
• supports sharding;
• supports collections and custom objects (in a JSON way, but at least it is a way...): I cannot imagine to deal with objects without being able to serialize collections;
• supports transaction, the proper way (cooperative transactions?? What ?);
• has a way to export data or to manually modifying data (via HTTP server): in case something bad happens, you can work with such data and you're not lost;
• supports polymorphism;
• while I feel safer with an objects database, its schema-less approach looks a fair compromise to get rid of RDBMS. I still think an objects database is better but RavenDB is better than SQL;

I'm mostly excited about different options to run RavenDB because such feature would inherently make Diavolo very scalable: basic needs, you go embedded; higher needs you switch to Web application; very high needs you switch to standalone server and then you can also start sharding... wow ! If it works, it's brilliant !

I didn't play enough with RavenDB to tell if all such promises will be met but I'm fairly confident they will, after playing with it for a few days. As I said, I will feel safer with a full objects database implementation but hey... you can't always get what you want !