Querying Collections with DocumentDB Studio

Solution  · 

I released a first Release Candidate (RC) of DocumentDB Studio (release 1.0.0.1).

DocumentDB Studio is to Azure DocumentDB what SQL Management Studio is to SQL Server and SQL Azure: a one-stop shop to manage and interact with your DocumentDB.

I posted an installation guide of the application and an upgrade guide (both very simple).

 

In this post I want to walk you through the new features of release 1.0.0.1:

Load folders before they are selected

This is a simple user-experience feature.

DocumentDB Studio lazy loads folders. We found that lazy loading a bit in the way of usage so we went a little more eager. When you open a folder, we eager load each sub folder (but no their sub folders).

This gives a more fluid user experience.

Query collection documents

The key feature of this release: querying!

In order to query a collection of documents, simply click on a collection folder:

You can then write any queries. Once you wrote your query, you can either click the red exclamation mark on top of the query text box or press F5.

For details on how to query DocumentDB see this documentation.

Telemetry

Let’s get the telemetry out of the way. I want to be totally transparent here. Actually the code for telemetry, both client and server is on codeplex so if you’re into it, you can look it up.

We’ve added telemetry to the smart client in order to gather intelligence on the scenarios you are using it with in order to orient progress.

We did bend backward in order to keep those telemetries anonymous. Let’s look at an example of telemetry entry (yes they are logged in a DocumentDB collection!):

{ "UserID": "nCNquA25eloB2VWHtjaN+oXti+Y=", "SessionID": "74ab88af-7fe7-402e-a9e8-b4ff8fc08ba1", "ReleaseVersion": { "TextVersion": "0.2.1.1" }, "UpTime": "00:00:00.0312492", "FeatureCounter": [ { "Feature": "ViewDocument", "Count": 10 }, { "Feature": "QueryDocument", "Count": 2 } ], "id": "5c124d49-686f-4cf5-97df-3be372e3b81f" }

A UserID!? Yes, a user-id. This is a key to aggregate telemetry’s entries in order to be able to calculate variation across users.

This isn’t the real user-id. Actually, it is a one-way hash of the user login-name and domain-name. A one-way hash means we can’t extract back the original user-id. So you are not sending your user-id to our telemetry service.

Session-ID is simply a GUID generated when you launch the app.

The most important part of the telemetry is the feature counter. We count how many times you use different features. This is key to learn what features are used more often.

So no sensitive information (e.g. real user-id) disclosing, simple anonymous statistics.

If you want to learn more, don’t hesitate to ask question in the comments section.

Conclusion

Querying documents is the key feature of this release and really enable us to explore the Azure DocumentDB product.

Learn More

Here are other articles I wrote about DocumentDB Studio:

More logistic posts:

Also, here are a couple of posts around Azure DocumentDB itself:

11 responses

  1. Sam – 2014-11-03 at 09:12

    It seems, with the new version (1.0.0.1) I can no longer see my stored procedures in my collection anymore. Is that the case or am I doing something wrong?

  2. Vincent-Philippe Lauzon – 2014-11-03 at 09:58

    Hi Sam,

    Stored Procs have never been exposed in the tool yet. There is a placeholder for it and will be render functional in future release.

    Cheers!

  3. kkap – 2015-04-05 at 14:42

    when can we expect the tool to allow us to do CRUD on storedProcs, Triggers or UDFs. And in the meantime, is there any other tool that would allow me to manage these.

  4. Hlatse – 2016-01-28 at 02:16

    its says it wants an ID and authorization ,i dont really understand what is the ID and Authorization key

  5. Laxman – 2016-09-09 at 01:24

    Error while reading the database The collection ‘xxx’ could not be read because it was created with a newer version

  6. Vincent-Philippe Lauzon – 2016-09-09 at 05:57

    Indeed, I believe the SDK used in the code base taps into an obsolete version of the API, hence the incompatibility.

    That tool has been superseded with the Azure Portal abilities, i.e. it now does everything that tool was doing. I would suggest using the Portal from now on.

    Unless you have a scenario where the tool would make more sense than the portal?

  7. jlsql – 2017-12-01 at 02:57

    Hi,

    What would be involved in updating it to the new API, The azure portal query experience is a bit limited with window size and it not being that adjustable, and only really scales well in 1080p, when i’m working on my little laptop, doing queries is a right pain as the screen resolution isn’t there. Doing SQL based queries in this tool was a nice experience. Are there no plans to update it?

  8. Vincent-Philippe Lauzon – 2017-12-01 at 03:51

    I’m not aware of plans to further improve that tool. What I would look at if I were you is the Storage Explorer tool that recently includes Cosmos DB support. https://azure.microsoft.com/en-us/features/storage-explorer/ It isn’t a web tool but it is available on multiple platforms.

  9. Vincent-Philippe Lauzon – 2017-12-01 at 03:55

    Have a look at https://docs.microsoft.com/en-us/azure/cosmos-db/tutorial-documentdb-and-mongodb-in-storage-explorer

  10. jlsql – 2017-12-01 at 04:07

    I found that the version on Github works with he new API

    https://github.com/mingaliu/DocumentDBStudio/blob/master/README.md

  11. Vincent-Philippe Lauzon – 2017-12-01 at 05:15

    That’s the ‘open source’ / community tool. Going forward I believe Storage Explorer is where the investment is going to go. I do not know which one has the most feature at the moment though.

Leave a comment