i believe there is a regression in version 0.0.9 which causes our mocks in the tests to fail on the following:

Traceback (most recent call last):
File "/Users/itaykeren/.vscode/extensions/ms-python.python-2022.6.2/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_resolver.py", line 192, in _get_py_dictionary
attr = getattr(var, name)
AttributeError: \'UpdateResult\' object has no attribute \'_UpdateResult__acknowledged\

in our tests, we are mocking update_one to return UpdateResult({}, False) in order to mock an upsert failure - meaning result.acknowledged is set to False

this worked fine with previous versions, but breaks on 0.0.9

i suspect its related to the changes introduced in https://github.com/michaelkryukov/mongomock_motor/pull/13

can you please look into it?

Hi, thank you for a great project!

We tried to use it in a real project and found out that it is impossible to use database methods due to a wrapper that thinks that every attribute is a collection name. Is it difficult to implement methods support in Database wrapper? We are trying to use list_collection_names method to access collections without knowing their names.

Hey Michael, I was referred to your library by the guys at mongomock who think my issue is probably with mongomock-motor. This is the ticket I raised with them. Does this make any sense? Do you agree with them?

Changes:

• Added masquerading mock classes as motor's original, so checks like isinstance(collection, AsyncIOMotorCollection) won't fail. It's possible there will still be issues if you expected to use tornado classes instead of asyncio, but I will wait for actual cases to somehow solve this.
• Added some async methods for collection.
• Added test that checks basic compatibility with beanie ODM.

Notes:

• Inspired by #1.

The current implementation of _normalize_strings transforms enum members into their representation, when it should give their value instead.

For example, with such an enum

class Importance(str, Enum):
    HIGH = "high"
    LOW = "low"

a cursor like Cursor({"importance": Importance.HIGH}) would see its filter transformed to {"importance": "Importance.HIGH"} instead of {"importance": "high"}, which will most likely not fetch anything.

Hey there, thanks for the great library!

Mongo-Thingy is a sync + async ODM that already has Mongomock and Motor as supported backends, so I really would love to add mongomock-motor to the list. :)

This PR fixes the errors that are raised by our test suite when adding mongomock-motor to the list of tested backends (see here if you're curious).

Basically, we just handle a few more things that should be interesting in other situations too:

• AsyncCursor.clone() and AsyncCursor.distinct() that are missing;
• AsyncMongoMockCollection.database that doesn't return an AsyncMongoMockDatabase but the underlying class instead;
• as well as AsyncMongoMockCollection.__eq__ and AsyncMongoMockDatabase.__eq__ that are missing.

It also adds a test file for Mongo-Thingy, inspired by test_umongo.py, in case you want to keep the compatibility alive.

aggregate() actually returns an AsyncIOMotorLatentCommandCursor instace, which is similar to AsyncIOMotorCursor but without the bells and whistles like sort(), limit() etc.

The Beanie .find(), .find_many() and .find_one() methods, when used with the Beanie search criteria syntax always return every document, regardless of the search criteria.

Using your test as an example and adjusting slightly, if we create two documents and then make a query that should only return one, we still get both documents returned. Example below:

@pytest.mark.anyio
async def test_beanie():
    client = AsyncMongoMockClient('mongodb://user:[email protected]:27017', connectTimeoutMS=250)

    await init_beanie(database=client.beanie_test, document_models=[Product])

    chocolate = Category(name='Chocolate', description='A preparation of roasted and ground cacao seeds.')
    tonybar = Product(name="Tony's", price=5.95, category=chocolate)
    newbar = Product(name="Test", price=5.95, category=chocolate)
    await tonybar.insert()
    await newbar.insert()
    
    find_many = Product.find_many(Product.name == "Test")
    assert find_many.motor_cursor
    assert await find_many.count() == 1 # This assert fails: 2 != 1

Additionally, you can see this happening in your test as it stands because of a typo. Line 37, there's a typo; "Chocolade" instead of "Chocolate". This query should return no documents, but your asserts on 38 and 39 still pass because the beanie syntax is essentially ignored.

I've found that these methods still work with pymongo syntax. For instance, modifying the search in my example above:

@pytest.mark.anyio
async def test_beanie():
    client = AsyncMongoMockClient('mongodb://user:[email protected]:27017', connectTimeoutMS=250)

    await init_beanie(database=client.beanie_test, document_models=[Product])

    chocolate = Category(name='Chocolate', description='A preparation of roasted and ground cacao seeds.')
    tonybar = Product(name="Tony's", price=5.95, category=chocolate)
    newbar = Product(name="Test", price=5.95, category=chocolate)
    await tonybar.insert()
    await newbar.insert()
    
    find_many = Product.find_many({"name": "Test"}) # using pymongo syntax here
    assert find_many.motor_cursor
    assert await find_many.count() == 1 # This now works with the pymongo syntax.

This test will pass because it uses pymongo syntax.

In short, it seems that the native beanie search syntax is essentially omitted and all documents are always returned in the case of .find() and the first document is always returned in the case of .find_one(). I may try and poke around a bit to see if I can work something out myself. Let me know your thoughts!

Hi, the thing is that MongoClient was not being initialized correctly. I discovered it while trying to use tz_aware parameter and queries always returned naive datetime instances.

I passed *args and **kwargs to the MongoClient initializer so all the MongoClient options can be used, but I haven't written tests for all options, just one for the tz_aware case, by the way.

This mocked method is required by the beanie ODM. This PR by itself isn't enough to make this new mock fully compatible, we will also need to patch Beanie to support the runtime type checking of mocked objects.

https://github.com/roman-right/beanie/ https://github.com/roman-right/beanie/blob/2e104ee9602624b7c5e694e3f0a5f56a8a39d924/beanie/odm/settings/collection.py#L71

When installing the package the tests folder is installed as well as a separate package.

When uninstalling with pip the following appears:

Uninstalling mongomock-motor-0.0.15:
  Would remove:
    .pyenv/versions/3.9.13/envs/venv_tb_web_server/lib/python3.9/site-packages/mongomock_motor-0.0.15.dist-info/*
   .pyenv/versions/3.9.13/envs/venv_tb_web_server/lib/python3.9/site-packages/mongomock_motor/*
    .pyenv/versions/3.9.13/envs/venv_tb_web_server/lib/python3.9/site-packages/tests/

This causes problems when I want to import from my tests folder.

A good solution would be to change setup.py

So after getting a document calling fetch_all_links() works however when using the keyword argument it doesn't. Thus you can't do queries comparing the linked document properties. For example the below would not work:

doc = await House.find_one(House.front_door.color == 'Blue', fetch_links=True)