Critical functions such as Select, Count and Contains are not currently available when querying TableStorage data.

If I only want a total number of rows that match a certain criteria I have no choice but to retrieve the data, count it and throw it away.

Adding support for Select would also help with heavy queries by only returning the data selected from a query.

Contains would be useful for searching. Using the Compare function is annoying.

Need to be able to sort on something other than the rowkey

Does what it says on the tin....really need better search capabilities over azure table storage.

The table storage entities are nice, but need more power. This should support secondary indexes (when those are added) and also partitions with mixed schema rows.

Atom is very verbose when fetching data, especially for Azure Tables. Please allow additional lightweight formats such as JSON and POX (plain old XML).

Azure tables need an option to support lists/arrays for per entity instance.

Both Google App Engine (http://code.google.com/appengine/docs/python/datastore/typesandpropertyclasses.html#ListProperty) and Amazon's simpledb both already offer this.

It enables an effective way to relate entities without the over head of traditional SQL.

Even if clearly impossible to have all relational features implemented, a mapping between EF entities and Azure Storage tables would be great, as would simplify the migration of the data layer to Azure.

Need to support all of this http://docs.amazonwebservices.com/AmazonSimpleDB/2009-04-15/DeveloperGuide/UsingSelect.html

It would be nice to be able to lock certain areas of Azure Storage to prevent operators/developers from deleting a table/container/queue by accident. Our specific need right now is for Azure Storage Tables but could potentially be for containers and queues. For example, it would be nice to lock a table to not allow deletion.

MSDN says the "take" operator is only supported for the first 1,000 rows...

I need to access row number 5,000 in a highly partitioned storage layout. Support for "skip" is a requirement if we are to continue development.

There is no good way to delete multiple entries in Table Storage. All you can do is delete one at a time. For logging tables this can become VERY expensive. It would be great if we had the ability to use Partitions as a way to delete logical groups of data in Table Storage in a single transaction.

This would allow for a partitioning scheme for grouping data in units that can easily be deleted. For example, logging data in WADLogsTable or rolling tables of data captured on a given partition can be archived easily and cleaned up.

to install Silverligh ClientAccessPolicy.xml on table storage and provide an editor. That way we can use table storage from within Silverlight.

If I choose to use Table Storage with an application that is under Traffic Manager, I would still like to maintain an affinity group for lower latency. In order to do this today I would need to syncronize data between the each of the storage nodes

The November '09 TableStorageSessionStateProvider could be improved in a few ways:

1.) Make it use DataConnectionString instead of blobServiceBaseUri, tableServiceBaseUri, AccountName, and sharedKey.

2.) Make it clean up old entries in the Sessions table and blobs in sessionprovidercontainer.

3.) Improve performance.

JSON is a pretty efficient format when compared to the current XML blob.

I'd like to use JSON for all my across the wire transfers and also only be billed for the smaller JSON overhead for archived data.

I'd like to see a solution similar to the SAS for blob storage added to table and queue storage as well.
Without it, having for example a Silverlight client working with table or queue storage is not possible in a safe way. Unless you pass the request through your own server, which is something I'd like to skip.