Tag Archives: Azure NoSQL

Creating a DocumentDB Repository Layer (Part 2 – Writing)

by in Programming and tagged , , | 3 Comments

“Last time, on Bill DeLude dot com…”

Hmm, it kind of loses its effect without a good narrator voice. Does someone have Morgan Freeman’s number? Because he could say that last time I talked about creating a data repository class using DocumentDB as the data store and covered the setup of the class and the read methods. This time, I’m going to go over the write methods.

But first a disclaimer before we get started. Not everything in this class is complete. As with normal programming, I like to take a highly iterative approach. First, I’ll make it work. Then I’ll improve some part of it. And then I’ll improve some other part, and so on. There’s two things conspicuously missing from today’s code. First, the write methods, as they are offered up, are synchronous. Second, it doesn’t allow for the Equipment type to change. I’ll address both of these in a later post.

First, I’m going to work on adding Equipment to the collection. Here’s the implementation of the AddEquipment method:

public Equipment AddEquipment(Equipment equipment)
{
    dynamic doc = Client.CreateDocumentAsync(CollectionLink, equipment)
        .Result.Resource;
    Equipment result = doc;
    return result;
}

Adding a document to a collection in DocumentDB is pretty straight-forward. All you really have to do is call CreateDocumentAsync with the link to the collection and the document you’re adding.

I made it a little more complicated because I like to return the added document back to the caller, so they can have any changes such as the id or a timestamp. To accomplish that, I need to get the Resource of the CreateDocumentAsync result as a dynamic type. Then I put that into an Equipment type and return the equipment.

Now that we can add documents, let’s make sure we can update them. Updating in DocumentDB is a two step process. You first have to get a document link by reading the collection, and then you replace the document with your changed version. Gone are the days of “UPDATE Equipment SET …” because DocumentDB, as with most NoSQL databases, just doesn’t work that way. Here’s the code for updating:

public Equipment UpdateEquipment(string id, Equipment equipment)
{
    var doc = Client.CreateDocumentQuery(CollectionLink)
        .AsEnumerable().First(d => d.Id == id);
    dynamic updatedDoc = Client.ReplaceDocumentAsync(doc.SelfLink,
        equipment).Result.Resource;
    Equipment result = updatedDoc;
    return result;
}

Notice that when I get the document this time, I’m not specifying a type to return. By omitting the return type, I get it as a Document and not as an Equipment. I want to do that because Equipment doesn’t have the self link I need to do the replace on the next line. Once you have the document, replacing it is pretty simple. Just call ReplaceDocumentAsync with the document’s self link and the new document. Returning the updated equipment requires some extra work, but it’s just like the Create.

Finally, we need to delete documents from the collection. This works a lot like updating: get a self link, then call a delete method. It looks like this:

 public void DeleteEquipment(string id)
{
    var doc = Client.CreateDocumentQuery(CollectionLink)
        .AsEnumerable().First(d => d.Id == id);
    Client.DeleteDocumentAsync(doc.SelfLink);
}

And that’s it. Now you have a full blown Equipment repository using DocumentDB as the data store.

The code that was used at the time of this writing is in my github at this commit.

Getting an Existing Database and Collection in DocumentDB

by in Programming and tagged , | 1 Comment

The API methods for creating databases and collections is easy to find, but how do you get a database and collection that’s already created? It’s definitely the more common use case, but it’s so obviously not there. Never fear, for we can wrap the queries used to get databases and collections in extension methods and pretend that it was always part of the API.

Did you say queries?

Yes, I did. You have to query the system database collection to get a link (not a URI, more like an ID) for your database, and ditto for your collection. The good news is that you don’t actually have to know where those collections live, because there are built in methods for querying them. It was almost easy.

First, get the Database

It’s kind of a two step process. Before you can get a collection, you have to get the database that contains that collection. But we’re going to make it easy with two simple extension methods. The first one will be used to get a Database object. You’ll rarely use this method directly, because the most common reason to get a Database object is to query it for the collection you need.

public static async Task<Database> GetOrCreateDatabaseAsync(
    this DocumentClient client, string databaseId)
{
    var databases = client.CreateDatabaseQuery()
        .Where(db => db.Id == databaseId).ToArray();

    if (databases.Any())
    {
        return databases.First();
    }

    return await client.CreateDatabaseAsync(
        new Database {Id = databaseId});
}

The method first tries to get the Database from the query. If it’s not found, then it creates the Database and returns it. I put the extension on DocumentClient because that is where CreateDatabaseAsync lives, so it made sense that the Get method would be, or appear to be, in the same place.

Then, get the collection

Now that we have a Database object, we can use its SelfLink to get the DocumentCollection. This extension method will be used a lot. It looks like this:

public static async Task<DocumentCollection>
    GetOrCreateDocumentCollectionAsync(
        this DocumentClient client,
        string databaseId,
        string collectionId)
{
    var database = await GetOrCreateDatabaseAsync(
        client, databaseId);

    var collections = client
        .CreateDocumentCollectionQuery(database.SelfLink)
        .Where(col => col.Id == collectionId).ToArray();

    if (collections.Any())
    {
        return collections.First();
    }

    return await client.CreateDocumentCollectionAsync(
        database.SelfLink,
        new DocumentCollection {Id = collectionId});
}

This works a lot like the other method, where it tries to get the collection and if it doesn’t exist then it creates the DocumentCollection and returns it. It also uses the other method to get the Database for its SelfLink. Note that this method asks for the database Id, not the object. I did that to make the two step process only look like one step from the outside.

Okay, now what?

This part’s easy. When you need a DocumentCollection object, just use the extension method. You’ll probably want to only do that once and store it in a static. We’re not going to put state in the DocumentCollection object, we really just want the DocumentLink. Here’s how you get it:

private const string DatabaseId = "ContentDB";
private const string CollectionId = "ContentCollection";
private static readonly DocumentCollection Collection =
    Client.GetDocumentCollection(DatabaseId, CollectionId).Result;

And then you use it for a document query like so:

public List<Content> GetList()
{
    var documentsLink = Collection.DocumentsLink;
    var contentList = _client
        .CreateDocumentQuery<Content>(documentsLink)
        .AsEnumerable().ToList();
    return contentList;
}

And that’s it, a very natural way to get the DocumentLink. Then again, maybe it makes sense to just store the DocumentLink as a static and just use that…

Consider that homework.