search

stijnsanders / TMongoWire

Delphi MongoDB driver
MIT License
102 stars 37 forks source link

This driver is not working with MongoDB 5.1/6.0 due to a change of the Wire Protocol #52

Closed synopse closed 2 years ago

synopse commented 2 years ago

Support of regular/legacy opcodes have been removed since 5.1/6.0. So we can't connect to any new version of MongoDB with this driver. https://www.mongodb.com/docs/v6.0/reference/mongodb-wire-protocol/#opcodes

OPMSG needs to be used for all communication, and will replace all other OP* opcodes with commands, like find insert etc... So it needs a deep rewrite of the code.

stijnsanders commented 2 years ago

Please have a look at the recent commit. The rewrite was not all that too deep :) I was able to keep most of the interface for TMongoWire and TMongoWireQuery.

As I'm not actively using MongoDB myself, I was not able to test as much and as deep as I would have liked to. I was not able to test (secure) authentication and secure sockets at all.

I'm still confused about namespace and collection names, but this was something I remember since the beginning of TMongoWire. Apparently when you install the (Windows?) mongod, the 'internal' database name is set to "test", and I remember it was not obvious to change this, but I forgot how I did it last time. (It's about twelve years ago now!) As I was testing, insert/update/delete works, even without a db.createCollection first, but mongosh still shows nothing for db.getCollectionNames(), strange. I'm not sure what I'm doing wrong. But TMongoWire appears to work again now. Your mileage may vary. Please keep me posted of any trouble/errors that do come up.

synopse commented 2 years ago

Yes, of course, the interfaces can be kept. But much of the driver has been rewritten for sure.

There is more testing to be done for sure. At first glance, its seems fine. My guess is that all the code in TMongoWire.Msg about several pending requests is not needed any more because of the new request/answer pattern of OP_MSG. I observed that the flags you are using are wrong: they are not the same for OP_MSG.

Nice to see your quick reaction!

stijnsanders commented 2 years ago

Ah, well I thought so to for a minute, and if you're strictly using a sequence of requests with each TMongoWire instance (from a single thread) you're right, but I've actually designed it to be 'thread-safe' to use a single TMongoWire instance over several threads. And then the FQueue dynamic kicks in: if two requests get sent (in consecutive Enter/Leave's of FWriteLock), but the responses come through in reverse order, the first Enter/Leave of FReadLock will queue one response and serve the correct one, the second one will serve the response from the queue!

Am I wrong about the flags? It's these right? Which other are there? Oh the mongoWire_QueryFlag* ones? Right, should have dropped those, those are deprecated.

synopse commented 2 years ago

I am not sure that the MongoDB server allows such interleaved requests in safety, for all versions. In fact, the most common way of the clients is to use a connection pool https://www.mongodb.com/docs/manual/administration/connection-pool-overview/

Yes, there is no flag at wire level but the OP_MSG flags, which are used for crc and exhaustAllowed - and you don't use either of the two IIRC.