25

I've created this post following the indications of the @AzureSupport Twitter account.

This morning (May 10th, 2017), while I was managing my Azure Resources I couldn't find my DocumentDB resources anymore.

But I noticed this:

azure-portal-capture-cosmosdb

I was wondering if it was just a bug or if DocumentDB is currently being renamed. For now I don't really want to touch my resources.

I cannot find any other occurrence of that Cosmos DB from Microsoft. Are other people seeing the same thing?

EDIT May 11th: Ok here is the announcement of Azure CosmosDB by Microsoft, apparently DocumentDB is becoming some kind of subset of that new Database system https://learn.microsoft.com/en-us/azure/cosmos-db/introduction

FabriceMk
  • 385
  • 3
  • 10
  • 1
    I'm seeing the same in the portal, looks like it is being renamed, probably be announced today at the Microsoft Build conference. – Andy Sinclair May 10 '17 at 08:45
  • 2
    Hope they fix the not-quite-sane API instead of renaming. Throwing exceptions if a document is missing isn't exactly the smartest decision. Forces people to use exceptions as control-flow statements – Panagiotis Kanavos May 10 '17 at 08:49
  • @PanagiotisKanavos And doing something else forces them to scatter a bunch of `if` conditions all over checking if something actually came back or not, even if they're pretty dang sure that should never happen. I'm not convinced that's better. – jpmc26 May 10 '17 at 16:54
  • 1
    @PanagiotisKanavos Only if you assume a missing document isn't an exceptional case. – JAB May 10 '17 at 18:21
  • It most defiinitely isn't. Just like a SQL query for a specific ID doesn't throw exceptions, asking for a doc shouldn't *throw*. It should return a status or error code, but not throw – Panagiotis Kanavos May 11 '17 at 06:51
  • @jpmc26 no it doesn't. They already have the equivalent to `AddOrUpdate`. The ConcurrentDictionary class has an AddOrUpdate *and* a *GetOrAdd* method. Databases *don't* throw if an entry is missing, they return empty results – Panagiotis Kanavos May 11 '17 at 06:55
  • @jpmcc26 besides - what are they doing now? How is the required `catch` any different from an `if`, apart from being a lot slower and disruptive? – Panagiotis Kanavos May 11 '17 at 06:56
  • @PanagiotisKanavos If you don't want to add the document if it's not there, those methods are useless. And those mean it makes sense to throw; you'd only use this method if a missing document is some kind of error. The fact databases don't typically behave this way doesn't inform us as to whether that's a good thing. Quite a few APIs for interacting with DBs provide a method that throws an error if an unexpected number of rows comes back, so it's not an uncommon need. Also, I don't believe a catch has any overhead if it's never invoked. So it's slightly more efficient if it's the rare case. – jpmc26 May 11 '17 at 19:24
  • @jpmc26 no *database* API does this. ORMs on top of them maybe. User libraries, maybe. It's still a very bad design that leads to very bad client code. DocumentDB documentation though presents this as a normal operation at [Step 6: Create JSON documents](https://learn.microsoft.com/en-us/azure/documentdb/documentdb-get-started#a-idcreatedocastep-6-create-json-documents) – Panagiotis Kanavos May 12 '17 at 06:58
  • @jpmc26 as for catch and overheads, that's completely wrong. The overhead is caused by *throwing* the exception, not catching it. This is probably more expensive than performing two calls, one to check for existense and a second one to read. – Panagiotis Kanavos May 12 '17 at 06:59
  • @jpmc26 finally remember that this was the case with HttpWebRequest and WebClient before .NET 4.5. They would throw if anything other than a 200 was returned, even a redirection. The .NET team itself considered this one of their biggest failures. The current HTTP classes don't throw unless explicitly instructed to do so – Panagiotis Kanavos May 12 '17 at 07:05
  • @PanagiotisKanavos You're spouting nonsense. 1. What library implements a feature is utterly irrelevant to whether the feature is a good idea or whether a lot of callers need it. 2. Your idea of "bad code" is dogmatic and not based on any facts. 3. An `if` check that happens every time is more expensive than a rarely thrown exception and its rarely invoked catch block. 4. If you seriously think that sending two network requests is cheaper than sending one and throwing an exception, then you should seriously question your abilities as a programmer. – jpmc26 May 12 '17 at 09:10
  • @PanagiotisKanavos 5. Of course it's a failure to throw an error for a non-error response. That is just utter stupidity. That doesn't in any way imply using errors for actual error conditions is bad. HTTP is also different, since the usage (and therefore the meaning) of codes is necessarily left up to *an arbitrary custom server*; the only thing that API can rely upon is the *protocol*. DocumentDB has a standard, well known response behavior that can be relied upon. – jpmc26 May 12 '17 at 09:10
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/144043/discussion-between-jpmc26-and-panagiotis-kanavos). – jpmc26 May 12 '17 at 09:28

5 Answers5

13

It looks like you are right, I can't find my documentdb resource either. They also renamed the azure-cli module.

This is how the blade looks like:

enter image description here

As you see, the subdomain is equal to the previous DocumentDB. I expect an announcement soon.

Community
  • 1
  • 1
Martin Brandl
  • 56,134
  • 13
  • 133
  • 172
13

It was announced today. Azure Cosmos DB is a superset of DocumentDB.

Microsoft is transitioning all existing DocumentDB customers and their data to Azure Cosmos DB for no additional charge.

Here is the official Microsoft documentation

Andy Sinclair
  • 2,143
  • 16
  • 18
  • 1
    For those reaching this question looking for historical context or more detail, here is the [official announcement Azure Cosmos DB](https://azure.microsoft.com/en-us/blog/azure-cosmos-db-microsofts-globally-distributed-multi-model-database-service/) on the Microsoft Azure blog, as well as a [letter to DocumentDB customers](https://azure.microsoft.com/en-us/blog/dear-documentdb-customers-welcome-to-azure-cosmos-db/ "Dear DocumentDB customers, welcome to Azure Cosmos DB! | Blog | Microsoft Azure"). – treehead Jun 07 '17 at 17:43
  • 1
    This should be the accepted answer. – Frank Fajardo Jun 22 '17 at 00:45
3

They have published a lot of code to AzureSamples in github repo.
https://github.com/Azure-Samples?utf8=%E2%9C%93&q=cosmos&type=&language=

Looking at these sample codes, it is not a simple rename maybe. It seems to be a product including Graph DB and Table Storage.

Takekazu Omi
  • 39
  • 1
  • 3
2

It would seem the name is changing but it has't been formally announced

If you try to buy cosmos db in azure portal it says:

Azure Cosmos DB is a fully managed, globally-distributed, horizontally scalable in storage and throughput, multi-model database service backed up by comprehensive SLAs. Azure Cosmos DB is the next generation of Azure DocumentDB.

It doesn't seem to be possible to buy the old 'document db' product and I have a suspicion that my document db has been upgraded as continuation tokens mysteriously grew over night which broke some of our devops tooling (fixes required increasing header sizes in tomcat and firewall).

owennewo
  • 301
  • 2
  • 3
0

Yes, seems like DocumentDB is renamed to Cosmos DB. Anyway, my previous databases and collections remain untouched. I've test CRUD functionalities on APIs which now use Cosmos DB and everything works perfect without changing any settings related with DB (authkey, endpoint etc.)

Marko
  • 141
  • 1
  • 8