Issue at using Beanie adapter for Fastapi-users for handling the entire persistent layer

[jolmedo]

Having a well described model and schema using Pydantic and Beanie syntax, there are some collections, represented by their Document classes, which are not been initialized by init_beanie function at the startup event of a Fastapi app.

Did someone know what could be the causes of such a behavior?

Fastapi-users set a very special class named User, which is one of the well initialized by the background Beanie engine. After that, I added my entire model which consists in several classes.

For example, from my product_category module:

from typing import Optional    
from beanie import Document, Indexed    

class ProductCategory(Document):
    category: Indexed(str, unique=True)
    description: Optional[str]

    class Settings:
        name = "product_categories"

From my product_subcategory module:

from typing import Optional    
from beanie import Document, Link    
from product_category import ProductCategory
    
class ProductSubcategory(Document):
    category_id: Link[ProductCategory]
    subcategory: str
    description: Optional[str]

    class Settings:
        name = "product_subcategories"

...and so. The outcome of init_beanie reflects an initialization of a collection named ProductCategory, not product_categories as I think it would happened, because of the Settings inner class with its property "name", and that's it. After several attempts, I really don't know how init_beanie creates proper collections, but it still gives me the same mistake:
beanie.exceptions.CollectionWasNotInitialized
Such a behavior is not documented, and that's why I assume I'm making something wrong. Can anyone know how to fix this?
If I remove all my Document classes, everything works fine. I'm trying to use the connection Fastapi_users set through Beanie to the MongoDB instance for my own purposes. Is it possible? Is there something "behind the scene" that prevents me from doing it?

While a deeper debugging session through Beanie, I found where the exception beanie.exceptions.CollectionWasNotInitialized is thrown:

@classmethod
    def get_settings(cls) -> DocumentSettings:

        #Get document settings, which was created on the initialization step
        #:return: DocumentSettings class

        if cls._document_settings is None:
            raise CollectionWasNotInitialized
        return cls._document_settings

So, according to this, there's a protected member named _document_settings which is None and it should be filled during the initialization step, meaning it should happen during the init_beanie call, am I right? That fragment code is at

... venv/lib/python3.9/site-packages/beanie/odm/documents.py

, started at line 871. My virtual environment Fastapi_users' deployment contains this:

beanie.__version__
'1.11.12'
fastapi.__version__
'0.85.0'
fastapi_users.__version__
'10.1.5'

At this point, I have to assume one of these things:

• my Document-based classes have something wrong, maybe some properties which are bad configured, something I've missed or
• there's something wrong inside my Fastapi_users deployment, particularly the Beanie adapter for Fastapi_users

My guess? the first one. Issue here is I can't find what I'm doing wrong, or where. Any help, any clarification you can provide will be appreciated.

Thanks in advance. I would appreciate any help you can provide.

[roman-right]

Hi! Can you please show the part of your code with the init_beanie call?

[jolmedo]

@app.on_event("startup")
async def on_startup():
 
    await init_beanie(
        database=db,
        document_models=[
            User,
            ProductSubcategory,
            ProductCategory        ],
    )

That code was made assuming the order of appearance in the document_models is relevant... I mean, I changed the model and now, ProductCategory contains a list of linked ProductSubcategory instances. I don't know if that assumption is correct, I mean, the assumption the order of appearance in document_models is relevant. Anyway, the exception goes on throwing.

[jolmedo]

Hi @roman-right .
Problem solved, my friend. Forget about the files I've already sent you. The key for solving this was given by you: ..."a one-file small example...", remember? I did it myself, and after fixing some module imports, everything works fine. Then, I got back to my project and conceptually, the biggest difference was the import clause: all relative paths were changed to absolute, meaning exactly what it is: class ProductCategory was in module product_category, when it was imported, the import clause looks like in the file (the file wasn't right, ok? But I've already told you to forget them). So, instead of

from .models.product_category import ProductCategory

I did

from dlivery.api.models.product_category import ProductCategory

And everything works fine. Maybe, Beanie can't follow relative paths, maybe there's a Pythonic-way to do this (to prefix some path in the relative ones, so Python inspection procedures can follow them, I really don't know), but simply putting the whole path was enough.
So, thank you very much for your attention and time, I hope you're feeling better by now,. Best regards

[mg3146]

Is it possible to get a more detailed explanation of what happened here? I'm having the same issue, and have classes (BaseModels, Documents, UnionDoc) in separate modules.