.NET Standard support for Table API

[SeanFeldman]

CosmosDB Table API is promoted as the replacement for Table Storage. Table Storage has support for .NET Standard. This library doesn't. Almost a year ago, it was mentioned that work on .NET Standard 1.6 is in progress and should be shortly released. As of today, the latest version of the CosmosDB .NET client does not support .NET Standard.

This impedes migration plans for those that have to support .NET Standard. Please provide an update and/or a milestone.

Update: latest client package name has changed to Microsoft.Azure.CosmosDB.Table

[kirankumarkolli]

@SeanFeldman which API are you consuming (Table API/document API)?

[SeanFeldman]

Table API @kirankumarkolli

[kirankumarkolli]

@SeanFeldman table API standard version is tracked for the end of year.

[SeanFeldman]

Thank you @kirankumarkolli

Not to be a PITA, but could you please either assign some milestone to this issue (I've renamed it to be more accurate) or raise another one? Even a label like table-api would help. Similar to what you've done for the graph API here. Thank you.

[kirankumarkolli]

Labeled it as Table.

[rnagpal]

@SeanFeldman DocumentDB Client SDK has a .NET Standard version which we released last year https://docs.microsoft.com/en-us/azure/cosmos-db/documentdb-sdk-dotnet-core As Kiran mentioned, we would be releasing .NET Standard for Premium Table SDK in the near future.

[SeanFeldman]

Thank you @rnagpal. I was specifically asking about Tables API 🙂 Will track this issue for progresses.

[SeanFeldman]

Microsoft.Azure.CosmosDB.Table client has GA-ed. Would be nice to see status/progress update on this issue. Thanks.

[yaronyg]

Microsoft has two different table offerings, Azure Table storage and Azure Cosmos DB Table API. They each target different audiences but use the same SDK. You can get a clear idea of how to choose which service by looking at https://docs.microsoft.com/en-us/azure/cosmos-db/table-introduction. I'm also tracking down the .net standard issue now with @kirankumarkolli

[SeanFeldman]

Thank you. @yaronyg Just to be clear - this issue is about .NET Standard support for Azure Cosmos DB Table API. Any mentioning of the Azure Storage tables is irrelevant 🙂

[yaronyg]

@SeanFeldman we don't currently support .net standard for Tables API but we do intend to eventually fix it.

[SeanFeldman]

@yaronyg any idea on the bulk part when to expect it?

[yaronyg]

@SeanFeldman not sure what you mean by bulk part?

[SeanFeldman]

@yaronyg ETA w/o overcommitting

[yaronyg]

@SeanFeldman Sorry for the slippage, but currently this is planned for the first 1/2 of 2018.

[johlrich]

It looks like a new version of the package hit nuget last week without netstandard support. Any updates to when we can expect to see that?

[yaronyg]

We are still on the same schedule as I previously specified, first 1/2 of 2018.

[paulinventome]

Is there any way to use TableAPI in Cosmo from a dot net core application at the moment, going through the older Windows.Storage libraries? I'm working on a large ish project and if i can't get table support then it will be AWS or similar instead.

[aboo]

Can I get a rain check on this please?

[kirankumarkolli]

Azure Cosmos table API is REST protocol compliant with Azure table storage. .NET standard Widnows storage SDK can be leveraged as an alternative.

[SeanFeldman]

@kirankumarkolli while it's true that the API is a REST protocol at heart, when working with .NET stack, you want to use a .NET SDK client rather than REST API.

You can prepare pizza dough, all the ingredients, and bake the pizza at home. Or can go to the restaurant. Relating to the metaphore, I guess we're paying by waiting @aboo 🙂

[aboo]

Cannot agree more with @SeanFeldman We've a backlog which makes a lot of sense to do with CosmosDB Tables Api and we've waited so long trying to avoid doing something in parallel with what MS is doing. Just yesterday we've decided to use CosmosDB SQL. Still would be great to have this SDK out ASAP. Thanks.

[TechInceptions]

First 1/2 of 2018 is almost upon us - should we look for alternative approaches?

[MisinformedDNA]

@yaronyg Are we still on track? Is there anything we can do to speed this along? 16 days left...

[yaronyg]

@MisinformedDNA @kirankumarkolli is a better person to ask than me. :)

[manigandham]

Side note:

All data in CosmosDB is stored the same underneath using its proprietary architecture and just exposed with different interfaces, so you can use any of the other APIs to get the same performance and scale. The Cassandra data model is a similar wide-column style to Azure Tables and it supports pretty much all of the same operations. The existing Storage Tables API also isn't going anywhere, and the pricing model is different too.

[joshlang]

Pleeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeease!

[SeanFeldman]

@manigandham if your data is stored using tables, and system is designed to work with Tables, I don't see how any ither API is relevant, regardless of how data is stored internally.

@kirankumarkolli @yaronyg it's June (happy Father's Day!). Is this still on schedule or has it changed? Thanks.

[joshlang]

Is there any system to put a bounty on stuff like this? I'd happy to pay some bitcoin or other crypto if it'd bump it up the priority list?

[TechInceptions]

We are just a few days away from July - and we are still waiting for the .NET Standard support CosmosDB Table API.

[RyanONeill1970]

I noticed CosmosDB support is possibly in the next EF Core 2.2 release. They may be implementing it that way instead.

[MisinformedDNA]

Except that they said, in this thread, that they would release this in the first half of 2018. And then went silent...

[TechInceptions]

Let me just say that EF cannot possibly be the answer.

[joshlang]

I've abandoned this and moved to a different solution. Thanks anyway.

[searbe]

It looks like you can use CloudTable from the Microsoft.WindowsAzure.Storage.Table namespace (i.e. the WindowsAzure Storage package at https://www.nuget.org/packages/WindowsAzure.Storage/). Create your CosmosDB instance, choose Table API when you create it, then:

var storageAccount = CloudStorageAccount.Parse("connectionstring");
var tableClient = storageAccount.CreateCloudTableClient();

(Obviously this only helps if all you're looking for is compatibility with the Table Storage API)

[SeanFeldman]

@searbe that client will not have the APIs specific to CosmosDB. Therefore it's more of a temporary workaround than a permanent solution. I agree with the above that the communication on this issue is poor.

Yes @kirankumarkolli @yaronyg, I'm looking in your direction. It's OK not to have an exact date. It's OK to let know that a date is pushed out. What is not OK is to let it sit w/o updates when customers ping and leave them wondering what's going on. I hope you take some time to update the issue. Thank you.

[joshlang]

Thanks @searbe … Yes, our solution worked using the old storage package, for the most part. There were some pesky issues though, making it an unreliable workaround. Thanks though.

[kirankumarkolli]

Apologies for the inconvenience. We will update this thread with more details and clear ETA in 2 weeks.

[wmengmsft]

We apologize for the inconvenience. We are fully committed to delivering a .Net Standard SDK for Table API. We are tracking for delivery by October or before.

[Gorthog]

We had 2 clients that cosmos DB table API would have been perfect for them but we went with an alternative solution because there is no .net core support. This decision actually resulted in us migrating the whole solution from azure to AWS, since splitting our solution across two cloud providers was not an option in both cases, and incurrs latency penalty and other issues. We would really like to come back, but as long as there is no .net core support, we can't.

[joshlang]

We're back on track using Azure Cosmos DB Table API.

But the lack of a .NET Standard library means we need horrible workarounds.

https://github.com/Azure/azure-cosmosdb-dotnet/issues/517 <-- This is a persistent problem that kills us.

Our workaround is to maintain TWO sets of projects. One .NET Standard/Core, and one .NET Framework (with Microsoft.Azure.CosmosDB.Table, which actually does work), and to coordinate code changes via linked source files. It also requires silly things so that it can compile in both projects, like this, because things are in different namespaces: namespace Microsoft.Azure.CosmosDB.Table { } namespace Microsoft.Azure.Storage { }// delete this crap once .NET Framework no longer needed namespace Microsoft.WindowsAzure.Storage.Table { }

One of our specific use cases, just as an example, is to scan various blockchains for deposits. Deposit addresses belonging to our customers are stored in Cosmos. When a Bitcoin block arrives, there might be say 10000 potential deposits. So we fire off 10000 concurrent Cosmos requests to say "Hey, does this deposit address exist?". 99.9% of them will return 404 (and needlessly throw an expensive exception, even though a 404 shouldn't be exceptional - https://github.com/Azure/azure-cosmosdb-dotnet/issues/219 ). Whatever does exist, we continue and do further processing.

It all works fine. Except with the old Azure Storage Table library, 0.01% of requests sometimes take 5 minutes to return (and occasionally it never returns at all unless we disable the network adapter). With the .NET Framework cosmos package, we don't have any problems at all, other than needing to use .NET Framework.

So, all in all, I suppose I'm just begging, in a long-winded way, for this to be done some time soon :)

[MisinformedDNA]

@joshlang Have you tried multi-targeting instead of multiple projects? This blog post has a great walkthrough of everything you should need to do that.

[joshlang]

@MisinformedDNA I had no idea that was possible. I've started implementing it to see if it's suitable, but yes, it definitely would simplify our workaround.

Thanks! :)

[TechInceptions]

@kirankumarkolli, on Jul 9, we were promised an update, as well as an ETA.

It would be much appreciated if we could have an update or an ETA.

Thanks

[manigandham]

@TechInceptions The next comment by @wmengmsft gives you the update:

We apologize for the inconvenience. We are fully committed to delivering a .Net Standard SDK for Table API. We are tracking for delivery by October or before.

[TechInceptions]

Yes. I actually cheered that comment. Time passed. And I forgot.

October it is. Thanks.

[pcoppney]

Ok, it is October. Any updates on this?

[wmengmsft]

We are almost there. We expect to push out the preview version of the .NET Standard SDK during the week of 10/15. Really appreciate your patience with us so far waiting for this release.

[pnda489]

Will this preview .NET Standard SDK be released through NuGet?

[pnda489]

We are almost there. We expect to push out the preview version of the .NET Standard SDK during the week of 10/15. Really appreciate your patience with us so far waiting for this release.

We really want to go on and use Cosmos DB. :( Any updates?