A.Jesse Jiryu Davis:
PyMongo is three and a half years old. The core module is 3000 source lines of code. There are hundreds improvements and bugfixes, and 7000 lines of unittests. Anyone who tries to make a non-blocking version of it has a lot of work cut out, and will inevitably fall behind development of the official PyMongo. With Motor’s technique, I can wrap and reuse PyMongo whole, and when we fix a bug or add a feature to PyMongo, Motor will come along for the ride, for free.
Original title and link: How I Asynchronized MongoDB Python Synchronous Library ( ©myNoSQL)
So; what are the goals?
- to operate as a fully-functional Redis client (obviously)
- to be thread-safe and non-blocking
- to support implicit database switching to help with multi-tenancy scenarios
- to be on-par with redis-sharp on like scenarios (i.e. a complete request/response cycle)
- to allow absolute minimum cost fire-and-forget usage (for when you don’t care what the reply is, and errors will be handled separately)
- to allow use as a “future” – i.e request some data from Redis and start some other work while it is on the wire, and merge in the Redis reply when available
- to allow use with callbacks for when you need the reply, but not necessarily as part of the current request
- to allow C# 5 continuation usage (aka async/await)
- to allow fully pipelined usage – i.e. issue 200 requests before we’ve even got the first response
- to allow fully multiplexed usage – i.e. it must handle meshing the responses from different callers on different threads and on different databases but on the same connection back to the originator
A driver library that doesn’t support connection pooling and is not thread safe should not be considered production ready. And the future belongs to drivers that also offer an asynchronous non-blocking timeout-enabled API.
Original title and link: BookSleeve: StackExchange Redis C# async Library (NoSQL databases © myNoSQL)