Home > .NET, Azure, C#, Mobile Services, Windows Phone, WinRT > Using the new system properties of Azure Mobile Services Tables from a client application

Using the new system properties of Azure Mobile Services Tables from a client application

26/11/2013

Some days ago an update to Azure Mobile Services has been released. As we can read on Carlos Figueira’s blog:

The main change is that they now have ids of type string (instead of integers, which is what we’ve had so far) […]. Tables have also by default three new system columns, which track the date each item in the table was created or updated, and its version. With the table version the service also supports conditional GET and PATCH requests, which can be used to implement optimistic concurrency. […]

Each new table created in a mobile service will have three new columns:

  • __createdAt (date) – set when the item is inserted into the table
  • __updatedAt (date) – set anytime there is an update in the item
  • __version (timestamp) – a unique value which is updated any time there is a change to the item

In this article we’ll focus on using the new table columns (also called system properties) from a client application.

First of all, we need to download the Azure Mobile Services SDK release 1.1.0 from NuGet. Then, as usual let’s create a MobileServiceClient in our app, pointing to the online service:

public static MobileServiceClient mobileServiceClient = new MobileServiceClient(
    "https://servicename.azure-mobile.net/",
    applicationKey: "");

As said before, each new table has three system columns, that are automatically handled by the Mobile Service (they are read-only for the client). Since they may not be necessary in many scenarios, by default they aren’t returned to the client, unless explicity requested. To obtain these values, each request to the service must have an additional query string parameter, called __systemproperties.

The client SDK manages this for us. We just need to add the appropriate properties to the class that maps the table record, using some new custom attributes:

[DataTable("Photos")]
public class Photo
{
    public string Id { get; set; }

    public string Description { get; set; }

    public string Uri { get; set; }

    [CreatedAt]
    public DateTime CreatedAt { get; set; }

    [UpdatedAt]
    public DateTime UpdatedAt { get; set; }

    [Version]
    public string Version { get; set; }
}

The CreatedAt, UpdatedAt and Version attributes are defined in the Microsoft.WindowsAzure.MobileServices namespace. Their are used to specify that the corresponding properties must be set using the relative values from the service.

Now we can make a request like this:

var table = App.mobileServiceClient.GetTable<Photo>();
var photos = await (from p in table
              select p).ToListAsync();

Since the Photo class contains the three system columns, the Client SDK automatically sets the new SystemProperties property of the table object at line 1 using the flags of the MobileServiceSystemProperties enumeration that correspond to the required values. In this way, it will be able to add the correct query string when making the request to the Mobile Service:

https://servicename.azure-mobile.net/
      tables/Photos?__systemproperties=__createdAt,__updatedAt,__version

The objects returned from the server will contain the values for __createdAt, _updatedAt and __version system columns, that will be assigned to the Photo instances. If we don’t need all the information, we can simply remove the attributes from the unwanted properties (or delete them at all), and the __systemproperties query string parameter will be updated accordingly.

When using untyped tables, we can obtain system columns as well by explicitly setting the SystemProperties property of the table:

table.SystemProperties = MobileServiceSystemProperties.CreatedAt 
    | MobileServiceSystemProperties.Version;

Note that this property can be used also with typed tables, for example if we have specified all the system columns in the class declaration, but in some scenarios we need only some values. So, at any time we can override the default behavior.

%d bloggers like this: