Issues connecting to CosmosDB about fluent-mongo-driver HOT 10 CLOSED

@Joannis Thanks for the quick response. 👍🏼
I hope it's not too much of an effort.

from fluent-mongo-driver.

I'll close this for now, feel free to reopen off you have any more queries!

from fluent-mongo-driver.

cc @Joannis

from fluent-mongo-driver.

Hey @thedan84, I haven't tried connecting to CosmosDB, and wouldn't know what's different about their connection phase. I'm creating an azure account so that I can dive into the issue.

from fluent-mongo-driver.

Hey @thedan84 , I seem to have found the cause of the issue. CosmosDB is violating the handshake specification, by providing an epoch timestamp rather than a BSON timestamp. I'm currently debating in what way to support this violation without affecting other code behaviour (too much).

from fluent-mongo-driver.

It's a bit more complicated than just one spec violation. I'll try to see what all the differences are.

from fluent-mongo-driver.

Hey @thedan84, I've found CosmosDB to be at the least a major pain in the ass, but I can send queries now.

A couple notes, for the interested (or people that for some insane reason want their own MongoDB+CosmosDB driver):

1. CosmosDB does not support OpMessage, even though it's supported API level indicates it does. If you for some "foolish" reason expect to use OpMessage, you're greeted by the amazing concept of "let's just close the connection without an error".
2. CosmosDB' MongoDB API is basically just a proxy to HTTP, and the errors are just as nice as you'd expect - an HTTP message dumped into the errmsg string.
3. While it's clearly documented in the BSON spec, cosmos DB expects you to read Date as an epoch timestamp, even tough Date is the formal definition by spec of these values. This is particularly noticeable in the isMaster handshake. So drivers just need to deal with the spec violation.
4. Even though MongoDB and SASL spec both state you can send "String", "Binary representing UTF-8 of a String" or "Binary representing the base64-ed value of the UTF-8". CosmosDB only accepts the second one. Any attempts at base64-ed data, or regular String data, is met by a confusing error.

Once all of these are resolved, I can do inserts and find ops. But don't expect the powerful MongoDB features such as aggregates to work fully as expected.

from fluent-mongo-driver.

If you're on discord, please contact me :)

from fluent-mongo-driver.

Hey @thedan84 , I happened to get an email this morning regarding the future of MongoDB for drivers. They're making some big changes, the most critical of which is the deprecation of their old protocol. That protocol has already been replaced in MongoDB 3.6, dating back to 2017.

Unfortunately for you, CosmosDB is quite heavily reliant on that old protocol right now. It uses OP_QUERY rather than OP_MESSAGE, as mentioned in my previous comment. That implies that MongoKitten will need to run in a customised legacy mode for CosmosDB to work. While I currently have a branch targeting CosmosDB, it's highly unlikely that I'll implement such code it in the official releases.

On the upside:

1. CosmosDB has an HTTP API
2. You can build a custom client that supports CosmosDB using MongoKittenCore, which will still maintain the necessary legacy protocol specification.

from fluent-mongo-driver.

@Joannis Thanks for the update. I'll see what I'll do then. Maybe I just use the official driver for work then. I got it working with that, but wasn't overly happy with the result. Thanks anyway for investigating and all the updates.

from fluent-mongo-driver.