[feature] Relations about beanie HOT 10 CLOSED

Hi @beratdogan ,
Yes. I plan to publish the first implementation this weekend.

It will support top-level fields only for now. The syntax will look like this:

class Window(Document):
    x: int
    y: int


class House(Document):
    window: Link[Window]
    name: str

Features, which it will support:

• fetching on find
• lazy fetching
• insert / cascade insert
• delete / cascade delete

from beanie.

Hello,
I love Beanie but just ran into this limitation in the current project. How far down the todo list is this feature?
It would be really good to have.

Br Johan

from beanie.

Hey @erajohl

Thank you.
Unfortunately, I didn't decide yet, how to implement this guy. The biggest problem is the query builder and trade-offs related to it.

from beanie.

Hi @roman-right - Any updates on this? Currently discussing to migrate our codebase using Beanie. Happy to contribute if you share your implementation thoughts to implement.

I'm stuck where/how should fetching/prefetching be done?

from beanie.

@roman-right -- It's great to hear you're actively working on this. I'm curious about implementation of the fetching/prefetching - it should not cause N+1 fetching problems. As my research on MongoDB drivers and they are all making N+1 queries for fetching from related collections. Making $lookup aggregations or querying related docs at once by after collecting could help the performance.

Feature need: Support for optional relations Optional[Link[...]]
Naming suggestion: Referenced[] might be more suitable name choice for this generic.

from beanie.

Hey @beratdogan ,

Yes, for the pre-fetching it will use lookup aggregations. This part is ready for single relations and will be implemented for lists soon. There is a small limitation for now related to this. It will support only top-level fields for now.
Later I'll try to support any field configuration.

from beanie.

+1

from beanie.

https://docs.mongoengine.org/apireference.html#mongoengine.fields.ReferenceField
https://pymongo.readthedocs.io/en/stable/api/bson/dbref.html

I assume we want to only do this explicitly instead of implicitly as it would make inheritance unworkable. Using the dbref field from pymongo has some advantages. Mongoengine's implementation is probably the best reference point. We can make a parallel setup by implementing a subclass of Fields. This would let us catch it and create a similar flow to mongoengine.

class Window(Document):
  width: int
  height: int

class House(Document):
  address : str
  windows: List[Window]
  favorite_window: Window

class EmbeddedHouse(Document):
  address : str
  windows: List[Window] = Embed(...)
  favorite_window: Window = Embed(...)

May need some kind of argument to handle List. It would be hard to implement anything similar to Lazy Reference without freaking pydantic validation out.

from beanie.

@zrothberg Good point.

I like your idea, thank you.

To solve the problem with pydantic validation it is possible to implement a custom field type. It will look like:

class Window(Document):
    width: int
    height: int

class House(Document):
    address : str
    windows: EmbedList[Window]
    favorite_window: Embed[Window]

For sure it will have some black magic inside, but the problem can be solved with this.

from beanie.

The feature is in PR.
I'll play with naming a little this weekend and on Monday it will be released.

from beanie.