MongoDB OData provider now supports arrays and nested collections

It’s been a while since I blogged about MongOData – a MongoDB OData provider that I wrote to cross MongoDB and OData protocol. Even though the provider has not reached it’s “Version 1.0” state, the response was quite encouraging: I received suggestions and bug reports, and this was indeed a good motivation factor. One of requests was to add support for collections. Property collections haven’t been supported by OData until the most recent protocol version (version 3), and such late attention to this topic is partly explained by the fact that property collections are not currently supported by Entity Framework which is often used to create OData services using WCF Data Services classes. But this should not be a limiting factor for document databases where arrays are used instead of relations in traditional SQL databases. To fill the gap I have upgraded OData protocol used by MongOData to version 3 and added creation of metadata for BsonArray properties.

Let me show how it works using a simple example. Imagine we have a JSON document with a root element colorsArray that consists of a collection of pairs (colorName,hexValue). Here’s the sample document:

{
    "colorsArray":[{
            "colorName":"red",
            "hexValue":"#f00"
        },
        {
            "colorName":"green",
            "hexValue":"#0f0"
        },
        {
            "colorName":"blue",
            "hexValue":"#00f"
        },
        {
            "colorName":"cyan",
            "hexValue":"#0ff"
        },
        {
            "colorName":"magenta",
            "hexValue":"#f0f"
        },
        {
            "colorName":"yellow",
            "hexValue":"#ff0"
        },
        {
            "colorName":"black",
            "hexValue":"#000"
        }
    ]
}

How will MongOData expose it if we create a MongoDB collection “Colors” and import there the document above? Let’s have a look at generated metadata for entity and complex type:

<EntityType Name="Colors">
    <Key><PropertyRef Name="db_id" /></Key>
    <Property Name="db_id" Type="Edm.String" Nullable="false" />
    <Property Name="colorsArray" Type="Collection(Mongo.Colors__colorsArray)" Nullable="false" />
</EntityType>
<ComplexType Name="Colors__colorsArray">
    <Property Name="colorName" Type="Edm.String" />
    <Property Name="hexValue" Type="Edm.String" />
</ComplexType>

Note the type name assigned to a property colorsArray. It’s a collection of items of a type Mongo.Colors__colorsArray – MongOData generates it’s type definition when it reads the first element. It is assumed that all array elements have the same structure – a reasonable assumption if we expect to generate the collection’s metadata.

Now let’s see how data exposed by this OData service can be consumed from the client. On a client side I am using Simple.Data OData adapter – a library that I also happened to maintain.

[Test]
public void Colors()
{
    var result = ctx.Colors.All().First();
    Assert.AreEqual(7, result.colorsArray.Count);
    Assert.AreEqual("red", result.colorsArray[0].colorName);
    Assert.AreEqual("#f00", result.colorsArray[0].hexValue);
    Assert.AreEqual("black", result.colorsArray[6].colorName);
    Assert.AreEqual("#000", result.colorsArray[6].hexValue);
}

MongOData can be downloaded as an MSI installer or as a NuGet package.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s