Azure-cosmos-dotnet-v3: EF Core provider gap: Provide proper synchronous version of various APIs

[divega]

The following methods don't have synchronous equivalents:

• CreateDatabaseIfNotExistsAsync()
• CosmosDatabase.DeleteAsync()
• CreateContainerIfNotExistsAsync()
• CosmosResultSetIterator<>.FetchNextSetAsync()
• CosmosQueryResponse<>.FetchNextSetAsync()
• CreateItemAsync<>()
• ReplaceItemAsync<>()
• DeleteItemAsync<>()

Since EF Core provides both synchronous and asynchronous APIs, in the EF Core provider implementation we need to choose between throwing NotSupportedException and applying workarounds that can cause threads to block and deadlocks.

This issue existed in previous versions of the SDK, and still applies to Cosmos SDK version 3.0.0.1-preview.

cc @AndriySvyryd @ajcvickers @kirillg

[kirankumarkolli]

Can you please more on how only async blocks/dead-locks but sync works?

[AndriySvyryd]

@kirankulkarni747 Calling an async method from a sync method requires some kind of blocking (like Task.Wait()) this goes against best practices as it can cause deadlocks. Using ConfigureAwait(false) to avoid deadlocks is brittle and can't be relied on.

[jackbond]

I think a better solution would be...

"Remove synchronous methods from EF Core"

[AndriySvyryd]

@jackbond For local databases and scenarios without strict memory constraints synchronous methods are usually more performant.

[jackbond]

@AndriySvyryd Dear Cosmos team, please supply an implementation of this SDK in machine language. Machine language is "usually more performant".

It's 2019, I'm dumbfounded that this is even a consideration.