search

BeanieODM / beanie

Asynchronous Python ODM for MongoDB
http://beanie-odm.dev/
Apache License 2.0
1.91k stars 201 forks source link

Motor 3.0.0 support #262

Closed fs86 closed 1 year ago

fs86 commented 2 years ago

Motor 3.0.0 was released a few days ago: https://www.mongodb.com/community/forums/t/mongodb-motor-3-0-0-released/160708. Do you plan to support the new version in the near future?

roman-right commented 2 years ago

Hey, I'm on it. I faced a breaking change about UUID representation there, which I'm fixing on the Beanie side. It looks like there are no more. If so, I'll publish the version, that supports motor3 in a few days.

athulnanda123 commented 2 years ago

@roman-right please consider issue #195 also seriously. Sub/Embedded Documents are badly needed. using beanie, i am not able to assign Children with MongoDB object id to sub documents (model coming as value of a key in parent model).

roman-right commented 2 years ago

@roman-right please consider issue #195 also seriously. Sub/Embedded Documents are badly needed. using beanie, i am not able to assign Children with MongoDB object id to sub documents (model coming as value of a key in parent model).

Hey. Yes, I do. Thank you. I do my best to add as many features as I can, but my time is limited. But Beanie is open for PRs - I will be happy to approve such a feature.

fs86 commented 2 years ago

Hey, I'm on it. I faced a breaking change about UUID representation there, which I'm fixing on the Beanie side. It looks like there are no more. If so, I'll publish the version, that supports motor3 in a few days.

Great to hear. Thanks!

fs86 commented 2 years ago

Is there any news on this?

roman-right commented 2 years ago

Hey. Yes. All the current features support Motor3. Since version 1.11.3. And I'll add new one-by-one soon

fs86 commented 2 years ago

Okay, thanks a lot!

aasay commented 1 year ago

@roman-right Once I move to any version past 1.11.2 beanie is broken for me when using UUIDs for keys. I can send the full trace if it helps, but this is what I am seeing.

File "pydantic/tools.py", line 38, in pydantic.tools.parse_obj_as File "pydantic/main.py", line 341, in pydantic.main.BaseModel.init pydantic.error_wrappers.ValidationError: 1 validation error for ParsingModel[TokenUUID] root <class 'bson.binary.Binary'> b'\x89Mj\x1cb\xfe\xae\xa1\xbe*z\x85\x02\x95\xf6,' is not valid (type=value_error.uuid.type) [20220818 15:26:58][ERROR][uvicorn.error:run_asgi:369] - Exception in ASGI application Traceback (most recent call last):

I am using a custom UUID class, but it is a subclass of UUID so I would think it would still work.

aasay commented 1 year ago

I found the source of the issue. In version 1.11.2 it looks like you initialized the ID type using the type specified in the model configuration.

new_id = self.__fields__["id"].type_(new_id)

In version 1.11.3 on you are using pydantic's parse_obj_as function, and since I am using a custom UUID class it doesn't how to handle that type.

new_id = parse_obj_as(self.__fields__["id"].type_, new_id)

@roman-right how do you feel about adding support for custom UUID classes or potentially using the old method of id validation?

aasay commented 1 year ago

I figured out the issue. I had a custom validator for pydantic and with the change in 1.11.3 the type of value was bson.binary.Binary and that caused my issue. Once I added support for that everything worked.