This project is read-only.

No database support yet? when It will occurs?

Feb 19, 2010 at 5:40 PM

Well, the lack of database support is preventing me of using but, I think that is a VERY good and well made project and It really deserves it, when it'll come to occur?

Feb 20, 2010 at 4:18 PM

Firetarster: database support is tricky due to an extensible schema.  I'm still evaluating solutions to overcome this obstacle.

Also, I'm curious, do you have need database support because you can't write to files or because you plan to have an extremely large amount of content?

Feb 21, 2010 at 4:10 PM

I do plan a lange ammount of content in a future, but, I just feel uncomfortable with writing xml files instead of having a data stored in a database. I'm using oxite right now but having some problems with it.

Thank you guys for the reply.

Mar 3, 2010 at 4:35 PM

Many blogs run off of the file system successfully.  I've been running AtomSite now on multiple sites off of the file system and it has been very reliable.

Mar 15, 2010 at 10:22 AM


what advantages do you see in databases? Transaction support, but that's not really useful for a blog. 
XML files make the app ultra flexible.

Mar 15, 2010 at 12:12 PM

I can see MongoDB  ( as the perfect database store for this project

There is a nice article : Implementing Blog Using ASP.NET MVC and MongoDb



Mar 16, 2010 at 2:04 AM
With MongoDB it may be difficult to obtain native support on hosting providers where a lot of blogs sit.   Obviously if you are self hosting then this is a non issue.

Persisting to XML or JSON via serialization seems to be a simple solution. If you did still want a object store persistence, then mayby something like

On Mon, Mar 15, 2010 at 9:12 PM, nachid <> wrote:

From: nachid

I can see MongoDB  ( as the perfect database store for this project

There is a nice article : Implementing Blog Using ASP.NET MVC and MongoDb

Mar 16, 2010 at 4:14 PM

I though I'd paste in part of an email conversation on the subject:

Erick Thompson

Regarding the schema modifications (which I see as the key issue), I believe that XML support in SQL Server 2005+ would work. What I was thinking is that the tables would contain columns for the required fields (per Atom spec), along with an XML column containing the remaining data. Then, a set of XML views would be created to combine the data into the proper Atom output, with instead of triggers to parse the data back into the store. I taken this approach in the past for generating dynamically formatted XML, and it works fairly well.


I like the XML model, as you can specify computed columns based on XQuery expressions, all while leaving the underlying XML intact.


I really like Erick's thoughts on this. So in general:

  • Atom/AtomPub/AtomSite standard fields go into columns
  • All the non-standard extension data (or entire entry) is stored in XML column