We currently require both CloudStorageAccount and TableName in all APIs, such that the initial table client resolving incurs a one-time cost of checking if the table exists.
This makes the creation of table partitions over the same table (i.e. the "Entities" default table name) more expensive than it otherwise would, forcing caching of the partition everwhere to avoid that.
This is annoying in particular for scenarios where you're using the same table for multiple entities, which cannot just create partitions for single-use, even though the entire REST API for table storage is stateless.
We can improve this by creating an abstraction over the combination of both CloudStorageAccount and TableName (an affinitized TableStorage) which caches the table client and ensures the check for table existence is performed only once.
We currently require both CloudStorageAccount and TableName in all APIs, such that the initial table client resolving incurs a one-time cost of checking if the table exists.
This makes the creation of table partitions over the same table (i.e. the "Entities" default table name) more expensive than it otherwise would, forcing caching of the partition everwhere to avoid that.
This is annoying in particular for scenarios where you're using the same table for multiple entities, which cannot just create partitions for single-use, even though the entire REST API for table storage is stateless.
We can improve this by creating an abstraction over the combination of both CloudStorageAccount and TableName (an affinitized TableStorage) which caches the table client and ensures the check for table existence is performed only once.