API consistency nitpicks for Azure.Data.Tables

Library or service name. Azure.Data.Tables

Is your feature request related to a problem? Please describe. I’ve been working on moving a project that uses Azure Table Storage heavily over to the new SDK. Love it so far. Just found a couple places that maybe could be brought to a more consistency state before the first RTM:

• 1. No Name or AccountName properties on TableClient.

  • These are very helpful for logging when passing around TableClient to helper methods.
  • QueueClient has these
  • BlobContainerClient has these

• 1. The TableItem type returned by TableServiceClient.GetTableAsync(...) has a TableName property instead of Name

  • No negative impact for me, just inconsistent
  • BlobContainerItem has Name (docs)
  • QueueItem has Name (docs)

• 1. No TableClient.ExistsAsync() method

  • Some of my tests could really use this. I have cases where I want to verify a table was not created.
  • Workaround: A small Query with no filter, catch the 404 (example)
  • QueueClient has this
  • BlobContainerClient has this

• 1. No TableServiceClient.GetTablesAsync(Expression<Func<TableSomething, bool>>) overload, you must write the OData yourself

  • I would prefer compile-time checks on comparisons against the available table properties for these queries
  • This is inconsistent with the Expression<Func<T, bool>> filter parameter on TableClient.QueryAsync<T>
  • Workaround: Use TableClient.CreateQueryFilter<TableItem> since fortunately (?) it doesn’t have ITableEntity constraint

• 1. No TableServiceClient.GetTablesAsync(prefix: ...) overload

  • This is helpful for test clean-up. I have many integration tests that run in parallel, with their own table name prefix.
  • Workaround: use an OData range query, bounded on the top by some max char (example)

• 1. No TableClient.DeleteIfExistsAsync

  • This is helpful for clean-up/finalize routines in distributed workflows.
  • Already reported here https://github.com/Azure/azure-sdk-for-net/issues/13984 but linked for reference.

• 1. No TableServiceClient.Uri

  • This is helpful for diagnostics, for example if you have the wrong cloud endpoint suffix provided
  • BlobServiceClient has this
  • QueueServiceClient has this

[rhythmnewt]

@christothes what about TableClient.ExistsAsync(), is that on the horizon as well?

No - An Exists method is inherently racy. For example, what decision could accurately be made after getting the result of Exists()? No matter the result, there is no guarantee that the result is still accurate when your code does something after that. You are better off just trying to do whatever you would have done and letting it either fail or succeed.

Sure that makes sense, it just wasn’t clear that it’s out of scope.

Thanks for the quick reply!

[christothes]

@christothes what about TableClient.ExistsAsync(), is that on the horizon as well?

No - An Exists method is inherently racy. For example, what decision could accurately be made after getting the result of Exists()? No matter the result, there is no guarantee that the result is still accurate when your code does something after that. You are better off just trying to do whatever you would have done and letting it either fail or succeed.