@asvetlov, thanks to you and @jettify, Motor 0.5 with asyncio is close to release. Could you review this example application that I plan to include in the tutorial?

The docs are rendered here:

http://emptysqua.re/aiotthp-example-docs/tutorial-asyncio.html#a-web-application-with-aiohttp

…issued

It looks like a workaround I wrote in Tornado was incorrectly incorporated into AsyncioMotorClient here https://github.com/mongodb/motor/pull/155/files#r851429040

if a user has opted into DeprecationWarnings as errors asyncio.get_event_loop_policy().get_event_loop() incorrectly suppresses the deprecation warning:

Python 3.10.4 (main, Apr  8 2022, 17:35:13) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import motor.motor_asyncio
>>> client = motor.motor_asyncio.AsyncIOMotorClient()
>>> client.test.pages.drop()  # this should raise a DeprecationWarning because it was called without a running loop
<Future pending cb=[_chain_future.<locals>._call_check_cancel() at /usr/lib/python3.10/asyncio/futures.py:384]>
>>> 

• added MotorDatabase()._fix_outgoing calling the delegate's method since we call add_son_manipulator on the delegate as well.
• applying _fix_outgoing when to_list retrieves data from Cursor's deque
• tests for to_list and control find_one, next_object (these two were unaffected by this bug)

Motor is a wrapper around Pymongo, extras available during pip install Pymongo should be available with Motor as well. I recently faced an issue regarding this and have raised it on Jira.

This change adds a new mongo_client argument when creating a new MotorClient or AsyncIOMotorClient instance, setting the delegate object to a pre-existing MongoClient instead of creating a new instance.

Background

I help maintain a project that uses Motor and has a very large number of tests, the majority of which involve MongoDB accesses. These tests use Tornado's AsyncTestCase and create new MotorClient instances in their setUp methods. As the tests run, they become progressively slower and, especially on weaker computers, eventually hang. Attaching a debugger to the hung Python process shows that there are a large number of active threads, the number roughly corresponding to the number of MotorClient instances that were created, thus far. These threads appear to be running the PyMongo _process_periodic_tasks code run through the periodic executor.

To avoid the hanging issue and improve overall test performance, we would like to be able to re-use the same MotorClient instance in all tests that need database access but, since MotorClient needs an IO loop and Tornado's AsyncTestCase creates a new IO loop for each test, that does not appear possible. A decent alternative is to re-use a single MongoClient instance for all tests and pass that MongoClient when creating a new MotorClient in the setUp method.

pymongo supports three optional dependencies, it would be nice to support them as well here, so that we can depend directly on motor[srv] instead of having to list both motor and pymongo[srv]

When I use the following code:

async with self.coll.find() as cursor:
    async for record in cursor:
        yield record

It's going to throw an AttributeError So I added the asynchronous context manager method so that I did not have to close the cursor when I was done with it