Support for DotNet library constructor of DocumentClient taking "Connection string", not the "Uri endpoint + string authKey"similar to other implementations of DocumentDB, or similar to Azure.Storage
We are currently working on this. Release expected by end of 2018.
I created a class for parsing connection string similar to how the CloudStorageAccount.Parse works. I tried to follow their pattern as closely as possible.
In the meantime, I posted some code that enables this for anyone that would like the functionality now. https://github.com/Azure/azure-documentdb-dotnet/issues/203
This idea's status is Unplanned, but the github issue is planned. Not sure what that means.
Rajesh Nagpal@MSFT commented
Thanks for your feedback. I'll add this to our backlog but this might take a while until we get to this. I assume this is not blocking any of the scenarios.
For example Azure.BlobStorage:
CloudStorageAccount _account = CloudStorageAccount.Parse(connectionString);
Compare to Azure.DocumentDB:
DocumentClient _client = new DocumentClient(new Uri(endpoint), authKey, connectionPolicy)
If anyone wants to have uniform access to different Azure storages it would be much simpler to initialize all of them in same manner (with connectionString!)
Dennis Frostlander commented
We are all used to storing connection specific data in <connectionStrings/> section. There are also good practices on how to not store connection strings in public repositories, replace connection strings during deployment, etc.
Why not implement similar connection strings for DocumentDb so that I could continue using the same practices?
CloudStorageAccount plays along nicely with this as it can parse one string which could be stored in connection strings. It would be nice to have an out-of-the-box support for similar functionality for DocumentDb.