Tables – CloudTableClient – Azure Storage Client v1.0

Classes

The Azure Storage Client v1.0 provides several classes to support Azure Table functionality:

CloudTableClient provides table management functionality such as create table, delete table and getting a list of tables. CloudTableQuery<TElement> represents an Azure Table query and provides support for retries. TableErrorCodeStrings provides strings describing various Azure Table errors. TableServiceContext adds Azure Table functionality to the ADO.Net Data Services class -  DataServiceContext. The TableServiceEntity class represents an entity in an Azure Table. The TableServiceExtensionMethods class provides an extension method that converts a TableServiceContext query into a CloudTableQuery<TElement> providing support for retries.

This post is about CloudTableClient. I will cover the other classes in other posts.

CloudTableClient

The CloudTableClient class is declared:

public class CloudTableClient {
    // Constructors
    public CloudTableClient(String baseAddress, StorageCredentials credentials);

    // Properties
    public Uri BaseUri { get; }
    public StorageCredentials Credentials { get; }
    public RetryPolicy RetryPolicy { get; set; }
    public TimeSpan Timeout { get; set; }

    // Methods
    public void Attach(DataServiceContext serviceContext);
    public IAsyncResult BeginCreateTable(String tableName, AsyncCallback callback, Object state);
    public IAsyncResult BeginCreateTableIfNotExist(String tableName, AsyncCallback callback, Object state);
    public IAsyncResult BeginDeleteTable(String tableName, AsyncCallback callback, Object state);
    public IAsyncResult BeginDeleteTableIfExist(String tableName, AsyncCallback callback, Object state);
    public IAsyncResult BeginDoesTableExist(String tableName, AsyncCallback callback, Object state);
    public IAsyncResult BeginListTablesSegmented(String prefix, AsyncCallback callback, Object state);
    public IAsyncResult BeginListTablesSegmented(AsyncCallback callback, Object state);
    public void CreateTable(String tableName);
    public Boolean CreateTableIfNotExist(String tableName);
    public static void CreateTablesFromModel(Type serviceContextType, String baseAddress, StorageCredentials credentials);
    public void DeleteTable(String tableName);
    public Boolean DeleteTableIfExist(String tableName);
    public Boolean DoesTableExist(String tableName);
    public void EndCreateTable(IAsyncResult asyncResult);
    public Boolean EndCreateTableIfNotExist(IAsyncResult asyncResult);
    public void EndDeleteTable(IAsyncResult asyncResult);
    public Boolean EndDeleteTableIfExist(IAsyncResult asyncResult);
    public Boolean EndDoesTableExist(IAsyncResult asyncResult);
    public ResultSegment<String> EndListTablesSegmented(IAsyncResult asyncResult);
    public TableServiceContext GetDataServiceContext();
    public IEnumerable<String> ListTables();
    public IEnumerable<String> ListTables(String prefix);
}

A CloudTableClient object can be created using either the CloudTableClient() constructor or the CreateCloudTableClient() extension method of the CloudStorageAccountStorageClientExtensions class.  For example:

CloudTableClient cloudTableClient = new CloudTableClient( https://myaccount.table.core.windows.net,
     new StorageCredentialsAccountAndKey(“myaccount”, “mykey”));

or

CloudStorageAccount cloudStorageAccount = CloudStorageAccount.FromConfigurationSetting(“DataConnectionString”);
CloudTableClient cloudTableClient = cloudStorageAccount.CreateCloudTableClient();

The latter technique requires that a configuration setting publisher has been configured previously through use of the SetConfigurationSettingPublisher() method of the CloudStorageAccount class. I described the use of this method in an earlier post.

A CloudTableClient object has synchronous and asynchronous methods for: create table, delete table, listing tables, and verifying table existence. The asynchronous table listing functionality supports paging in the case of long lists through support of continuation tokens. The paging functionality is exposed through EndListTablesSegmented(). The timeout for all requests can be set through the Timeout property.

Since there is a possibility that a request operation might fail the RetryPolicy property allows a RetryPolicy to be set. A RetryPolicy is a delegate for which the RetryPolicies class provides some standard retry policies: NoRetry() which attempts an operation precisely once; Retry() which attempts an operation a “specified number of times with a fixed time interval between retries;” and RetryExponential() which retries “a specified number of times with a randomized exponential backoff scheme.” The default retry policy appears to be RetryExponential().

Note that the CreateTableIfNotExist() method performs two http requests – the first checking if the table exists and the second creating it if necessary. Also, the ListTables(String prefix) method makes an identical http request to ListTables() and then filters the resulting list of tables on the client.

Examples

protected void CreateTable(String tableName)
{
    CloudStorageAccount cloudStorageAccount = CloudStorageAccount.FromConfigurationSetting(“DataConnectionString”);
    CloudTableClient cloudTableClient = cloudStorageAccount.CreateCloudTableClient();

    cloudTableClient.CreateTable(tableName);

    Boolean doesTableExist = cloudTableClient.DoesTableExist(tableName);
}

protected void ListTables(String tableNamePrefix)
{
    CloudStorageAccount cloudStorageAccount = CloudStorageAccount.FromConfigurationSetting(“DataConnectionString”);
    CloudTableClient cloudTableClient = cloudStorageAccount.CreateCloudTableClient();

    IEnumerable<String> listTables = cloudTableClient.ListTables();
    Int32 countListTables = listTables.Count<String>();

    IEnumerable<String> listTablesPrefix = cloudTableClient.ListTables( tableNamePrefix);
    Int32 countListTablesPrefix = listTablesPrefix.Count<String>();
}

protected void DeleteTable(String tableName)
{
    CloudStorageAccount cloudStorageAccount = CloudStorageAccount.FromConfigurationSetting(“DataConnectionString”);
    CloudTableClient cloudTableClient = cloudStorageAccount.CreateCloudTableClient();

    Boolean deleteTable = cloudTableClient.DeleteTableIfExist(tableName);
}

About these ads

About Neil Mackenzie

Azure Architect at Satory Global.
This entry was posted in Storage Service, Windows Azure. Bookmark the permalink.

3 Responses to Tables – CloudTableClient – Azure Storage Client v1.0

  1. Samee says:

    Hey Mackenzie.Hope u will be doing fine. You have explained the way to delete a table from Azure Table but you have not told the way to delete only a specific data from tables rather than deleting the Whole Table. Like i want to delete only 15 days old records.I have done the saving process to azure tables and i am also able to delete a single record only because i dont know the Partition Keys and Row Keys of the records(they are GUIIDs). I have made an extra field in the tables named as PlayerId and Date Field while saving and deleting. But when i try to delete the records on the basis of these two keys it requires Partition key and Row key of the record too.Is there any way of deleting the records on the basis of custom attributes which i am creating at the time of storing data.

  2. Neil says:

    Samee -The primary, and only, key for an Azure table is the combination of PartitionKey and RowKey. Performing a query without specifyingy both of these causes a partial or complete scan of the table and is inadvisable for large tables. Consequently, you should choose appropriate – searchable – values for PartitionKey and RowKey. GUIDs are not really good values for these properties. The Azure whitepaper (http://go.microsoft.com/fwlink/?LinkId=153401) although now somewhat dated has some advice on the construction of PartitionKey and RowKey.Furthermore, if you look at the REST API, the definitive way to access the Azure Storage service, you can see that the Delete Entity operation REQUIRES the PartitionKey and RowKey (http://msdn.microsoft.com/en-us/library/dd135727.aspx). In other words, you cannot delete an entity without knowing the PartitionKey and RowKey. You can get these either by prior knowledge (i.e., you know how to construct them) or as a result of a (scanning) query which retrieved them. The best solution is to construct the PartitionKey and RowKey out of the parameters you wish to query on – perhaps you use the date for PartitionKey and some other unique element of the data for the RowKey – and delete the entity directly. If you want to delete an entity it is more efficient to attempt the delete and handle the failure (if, for example, it doesn’t exist) than it is to query for the entity and then delete it. Even though it seems extra work to handle the failure the design mantra for cloud-scale systems is "design for failure."Given that all deletes happen on an entity-by-entity basis it may even be worth designing your tables for deletion. That is, if you know you will be doing a lot of deletes – e.g., you add and delete data on a rolling basis – it may be worth architecting your data so you can delete entire tables rather than having to delete individual entities. For example, you could collect data for different months into different tables so that you can delete a months worth of data with a single Delete Table operation instead of millions of Delete Entity operations.

  3. Pingback: Exploring Windows Azure Storage APIs By Building a Storage Explorer Application - Paolo Salvatori's Blog - Site Home - MSDN Blogs

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