I am working with .NET V12 which meets the need for Blob but I am in need of using table storage. Currently V12 does not support Table. Are there any plans to support Table or we should start looking to move to CosmosDB?
If the answer is yes would it be fair to assume Tables is something that should not be considered going forward.
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Wmengmsft, @MehaKaushik, @shurd, @anfeldma-ms
Hi @athrayee. Azure Tables has its own stand-alone client library; it is not part of the Azure Storage library. Tables is currently in beta, and the package is available via Azure.Data.Tables on NuGet.
Azure Tables has its own stand-alone client library; it is not part of the Azure Storage library. Tables is currently in beta, and the package is available via Azure.Data.Tables on NuGet.
great to see this new client library released after https://github.com/Azure/azure-sdk-for-net/issues/6860! just curious, what would be the differences between Azure.Data.Tables and Microsoft.Azure.Cosmos.Table onwards? The new library seems to have the same features (works with both generic Table storage and CosmosDB)
in other words, for a new project that we're bootstrapping, should we onboard with Azure.Data.Tables?
also kind of curious, what makes the table library special (not part of Azure.Storage.)?
For new development, we would recommend using the Azure.Data.Tables package and the Azure.[[ AREA ]].[[ SERVICE ]] packages for other services. The caveat with Tables is that it is still in beta status and, therefore, we don't recommend using it in a production application until it has been GA'd.
The Microsoft.Azure.Cosmos.Table package will continue to be supported with receive bug fixes and critical updates for the foreseeable future; unfortunately, I don't have definitive date to share, but it's safe to say that the timeline is most likely measured in years. That said, at some point in the near future, it will stop receiving new features and enhancements. Unfortunately, once again, I don't have a firm timeline.
With respect to the motivations and differences, as Azure has matured and been embraced by a more diverse group of developers, we have been focused on learning the patterns and practices to best support developer productivity and to understand the gaps that the .NET client libraries have.
There were several areas of consistent feedback expressed across the Azure client library ecosystem. One of the most important is that the client libraries for different Azure services have not had a consistent approach to organization, naming, and API structure. Additionally, many developers have felt that the learning curve was difficult, and the APIs did not offer a good, approachable, and consistent onboarding story for those learning Azure or exploring a specific Azure service.
To try and improve the development experience across Azure services, a set of uniform design guidelines was created for all languages to drive a consistent experience with established API patterns for all services. A set of .NET-specific guidelines was also introduced to ensure that .NET clients have a natural and idiomatic feel that mirrors that of the .NET base class libraries. Further context, rationale, and details are available in the linked guidelines.
also kind of curious, what makes the table library special (not part of Azure.Storage.)?
On that, I don't have any direct insight. @christothes may have a bit more context to share.
also kind of curious, what makes the table library special (not part of Azure.Storage.)?
On that, I don't have any direct insight. @christothes may have a bit more context to share.
The main reason the table library is special is its support for both Storage Account and Cosmos DB service back ends. Check out this blog post for a bit of context.
thanks @jsquire and @christothes!!
We shipped Azure Tables Beta 1 - you can find it here: https://aka.ms/azsdk/releases
Most helpful comment
The main reason the table library is special is its support for both Storage Account and Cosmos DB service back ends. Check out this blog post for a bit of context.