Intro

In the previous post I have described how to work with large amounts of data in Azure Table and provided basic query samples. In this post I am going to describe TableRequestOptions class and show how to use it.

Prerequisites

Refer to previous posts to get started with Azure Storage Table Service.

Code

TableRequestOptions is a very important class that are used as parameters of all CloudTable methods that interact with Azure Storage Service.

TableRequestOptions represents a set of timeout and retry policy options that may be specified for a request against the Table service. Also it specifies encryption settings. Some properties of this class are self-explanatory such as ServerTimeout, others are not.

RetryPolicy allows you execute some operations repeatedly (i.e. retry those operations) if an error has occurred while executing those operations and certain conditions are met. They also allow you to define how many times the operation should be retried and with how much delay.

RetryPolicy can be one of the following:

  • NoRetry - a default retry policy. The name speaks for itself.
  • LinearRetry - represents a retry policy that performs a specified number of retries, using a specified fixed time interval between retries. Default number of retries is 3, default interval is 30 seconds. This policy can help if you think resource is unavailable because of transient failure.
  • ExponentialRetry - represents a retry policy that performs a specified number of retries, using a randomized exponential back off scheme to determine the interval between retries. Default number of retires is 3, default interval is between 3 and 120 seconds. This policy can help if you are fighting with throttling.

Refer to Storage Client Library 2.0 – Implementing Retry Policies for more info.

The next parameter is MaximumExecutionTime. As name suggests in sets the maximum execution time across all potential retries for the request.

A very interesting parameter is LocationMode, it allows to specify where request should go, it can be:

  • PrimaryOnly - default. All requests are always sent to a primary location.
  • PrimaryThenSecondary - requests are sent to the primary location first, if a request fails, it is sent to a secondary location.
  • SecondaryOnly - all requests are always sent to a primary location.
  • SecondaryThenPrimary - requests are sent to the secondary location first, if a request fails, it is sent to a primary location.

Another parameter is PayloadFormat. When I first time saw this parameter, I thought it will allow me to switch between JSON and XML. But it has only different types of JSON payload:

  • Json
  • JsonNoMetadata
  • JsonFullMetadata

The type of payload affects the response size, you can play with this parameter to make some optimizations.

There is one more parameter that can dramaticaly affect performance. Take a look on the following code:

var profile = table.Execute(TableOperation.Retrieve<Profile>("AU", "EMP00000005", new List<string> { "Title" })).Result;
Console.WriteLine(profile);

This code will output following lines:

:: John Doe 5,

You can see that PartitionKey and RowKey has not been loaded because we requested only Title to load. In previous versions of Azure Storage library PartitionKey and RowKey had been loaded by default. We still can control this behaviour by switching ProjectSystemProperties flag. So the following code will load PartitionKey and RowKey by default.

var opts = new TableRequestOptions();
opts.ProjectSystemProperties = true;
var profile = table.Execute(TableOperation.Retrieve<Profile>("AU", "EMP00000005", new List<string> { "Title" }), opts).Result;
Console.WriteLine(profile);  

I will cover PropertyResolver property in post dedicated to EntityResolver.

Azure Storage Table supports encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client. The library also supports integration with Azure Key Vault for storage account key management. EncryptionPolicy and RequireEncryption properties can be used to control encryption. Encryption is a very complex topic, I will make a post about Azure Key Vault and encryption someday.

Summary

Azure Storage Table library is very simplistic, but yet flexible. Developers can specify different request options to control the behaviour. In this post I have described the TableRequestOptions class and its parameters. I highlighted basic usage scenarios. In the next post I am going to describe how to use Shared Access Policies and Shared Access Signatures with Azure Storage Table.


;