hexadecimal

In my previous post, I gave some thoughts about Oxite. Never one to sit idle, I proceeded to tackle the first item on the list.

Oxite comes with an SQL data provider, which is great. But I wanted an XML data provider, so the content could be stored like in dasBlog.

As an experiment, I created an XSD schema from the database that ships with Oxite, and implemented a class called OxiteDbContext, which serves as a cache.

public static class OxiteDbContext
{
    private static OxiteDb mDatabase = new OxiteDb();
    private static string mFilename =
      HttpContext.Current.Server.MapPath(
      "~/App_Data/oxite.xml");

    static OxiteDbContext()
    {
        mDatabase.ReadXml(mFilename);
    }

    public static void Save()
    {
        lock (mDatabase)
        {
            mDatabase.AcceptChanges();
            mDatabase.WriteXml(mFilename);
        }
    }

    public static OxiteDb Data
    {
        get
        {
            return mDatabase;
        }
    }
}

I then copy/pasted the code from the SQL provider and re-mapped the LINQ to SQL code to the new typed DataSet, like so:

public Area GetArea(string areaName)
{
    return (from a in OxiteDbContext.Data.oxite_Area
            where a.SiteID == siteID && string.Compare(
            a.AreaName, areaName, true) == 0
            select ProjectArea(a)).FirstOrDefault();
}

It’s not exactly impressive, as it stores the entire dataset in a single XML file, and whenever it saves anything, it re-writes the entire XML file.

Imagine that you have 200 MB of posts on your Blog, someone adds a comment, and the blog re-writes 200 MB on the disk. Not exactly “best practice”, but it will suffice as a first experiment.

A better approach would be to make more use of the disk structure, and split the schema into separate XML files, to minimize disk access.

One plausible structure could be like this:

Much better!

Stay tuned for the next part in the series!

As always, source code included: