How can we improve Azure Cosmos DB?

connection string

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

283 votes
Sign in
Sign in with: oidc
Signed in as (Sign out)
You have left! (?) (thinking…)
Sviatoslav shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: oidc
Signed in as (Sign out)
  • Rajesh Nagpal@MSFT commented  ·   ·  Flag as inappropriate

    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.

  • Sviatoslav commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

Feedback and Knowledge Base