Typical issue‘One of the request inputs is not valid’ when Working with the Windows Azure Development Storage

Cesar De la Torre

One of the typical issues is getting the error “One of the request inputs is not valid” that occurs when testing the application with empty tables in development storage. This is because Development Storage currently requires the schema for an entity stored in a table to have been previously defined before you are allowed to query it.

WORKAROUND

The workaround is simple, we just need to insert, and then delete, a dummy row into the Windows Azure tables if the application is running in the development fabric. During the initialization of the web role, it is a good idea if the application checks whether it is running against local development storage, and if this is the case, it adds, and then deletes, a dummy record to the application’s Windows Azure tables (It will be done just the first time, per Entity, when working against the Development Storage).

That code can be added using an extension method, for instance.

Here you have extended info about it:

http://msdn.microsoft.com/en-us/library/ff803365.aspx

Working with Development Storage (Taken from the above URL)

There are some differences between development table storage and Windows Azure table storage documented at http://msdn.microsoft.com/en-us/library/dd320275.aspx. The team at Adatum encountered the error “One of the request inputs is not valid” that occurs when testing the application with empty tables in development storage. The solution that Adatum adopted was to insert, and then delete, a dummy row into the Windows Azure tables if the application is running in the development fabric. During the initialization of the web role, the application calls the CreateTableIfNotExist<T> extension method in the TableStorageExtensionMethods class to check whether it is running against local development storage, and if this is the case, it adds, and then deletes, a dummy record to the application’s Windows Azure tables.

Note:

Don’t assume that local development storage will work in exactly the same way as Windows Azure storage.

Markus says:

You should consider adding dummy records to all tables in local development storage.

The following code from the TableStorageExtensionMethods class demonstrates how the aExpense application determines whether it is using development storage and how it adds and deletes a dummy record to the table.

public static bool CreateTableIfNotExist<T>(
    this CloudTableClient tableStorage, string entityName)
    where T : TableServiceEntity, new()
{
    bool result = tableStorage.CreateTableIfNotExist(entityName);

    // Execute conditionally for development storage only
    if (tableStorage.BaseUri.IsLoopback)
    {
        InitializeTableSchemaFromEntity(tableStorage,
            entityName, new T());
    }
    return result;
}

private static void InitializeTableSchemaFromEntity(
    CloudTableClient tableStorage, string entityName,
    TableServiceEntity entity)
{
    TableServiceContext context =
        tableStorage.GetDataServiceContext();
    DateTime now = DateTime.UtcNow;
    entity.PartitionKey = Guid.NewGuid().ToString();
    entity.RowKey = Guid.NewGuid().ToString();
    Array.ForEach(
        entity.GetType().GetProperties(BindingFlags.Public | 
        BindingFlags.Instance),
        p =>
        {
            if ((p.Name != "PartitionKey") &&
                (p.Name != "RowKey") && (p.Name != "Timestamp"))
            {
               if (p.PropertyType == typeof(string))
               {
                   p.SetValue(entity, Guid.NewGuid().ToString(),
                       null);
               }
               else if (p.PropertyType == typeof(DateTime))
               {
                   p.SetValue(entity, now, null);
               }
           }
       });

    context.AddObject(entityName, entity);
    context.SaveChangesWithRetries();
    context.DeleteObject(entity);
    context.SaveChangesWithRetries();
}

Cesar De la Torre Principal Program Manager, Azure

Follow