[BUG] Beanie should have a way to handle an `id` field different than underlying `_id`

[nahuel]

Seems like defining id on the beanie.Document base class is a miss-design, as it's very frequent that your domain model has an id field (business related, a very common field name) distinct from the underlying Mongo _id field.

For example:

import pydantic
import beanie

# Pure pydantic model, e.g. maybe generated from OpenAPI specs, used everywhere:
class User(pydantic.BaseModel):
    id : str
    name : str 
    # ...

# Now we want to store it as such on Mongo
class UserDB(beanie.Document, User)
   class Settings:
        collection_name = "users"

Pylance detects the bad override Base classes for class "UserDB" define variable "id" in incompatible way

This also happens when you must create Beanie models from existing Mongo collections that use a business related id field. In that case you cannot use Beanie.

As Pydantic doesn't support fields starting with _, maybe _id can be aliased to something more specific and less prone to collision, like mongoDocumentId and still be mapped to the underlying _id.

[unexceptable]

I know that in my particular use case I want to pretend _id just doesn't exist. I like that id is just a mapping to the underlying _id but that itself isn't well handled since in the OpenAPI schema it still shows as _id if I decide to expose the db model directly as the return API return type.

I feel like there is there is a bunch related to _id vs id that is odd with Beanie and needs to be fixed.

I think most people are in the same boat as me and just want to pretend _id doesn't exist, and use id, and that should be the default, and the schema should return as id not _id.

But for uses cases like yours, where you want _id AND id as distinct fields, that should be allowed, with you able to alias _id to another field.

[trojanEcstasy]

Bumping for visibility.

I’ve run into this bug as well.

[github-actions]

This issue is stale because it has been open 30 days with no activity.

[ice6]

Bumping for visibility. similar problem with prisma, it is a crazy world. :P

[ghmahdi21]

You can do:

from beanie import Document
from pydantic import Field

class User(Document):
    user_id: int = Field(alias="id")  # This field in the database is "id"

[cleonello]

Just started prototyping a new app with beanie and have the same issue. It is common to have an "id" field which needs to be preserved and has nothing to do with the underlying "_id" field. I agree that in many cases beanie's mapping "_id" to "id" is convenient, but there needs to be some option to expose "_id" as "_id" so a separate "id" field can be used.

[cleonello]

Note for anyone reading this thread. Tried @ghmahdi21's idea :

class MyDoc(Document):
    my_id: int = Field(alias="id")  # This field in the database is "id"

but it throws:

Value error, Id must be of type PydanticObjectId [type=value_error, input_value=9799, input_type=int]

validation_alias and serialization_alias produced the same result (for me). It appears that my incoming data's "id" field, which is an int, gets validated by Pydantic as a PydanticObjectId (since internally beanie's "id" field is a PydanticObjectId) and fails.

The work around I am using is a model_validator before Pydantic validation which assigns the "id" to "my_id" and drops the "id" field like this:

@model_validator(mode='before')
@classmethod
def fix_beanie_id_field(cls, data: Any) -> Any:  
    if isinstance(data, dict):  
        if 'id' in data:
            data['my_id'] = data['id']
            del data['id']
        else:
            raise ValueError("Incoming Object does not have an 'id' field")
    return data

This still doesn't address the fact that my model cannot have an "id" field that is in line with the incoming data and business logic. We shouldn't have to use any workarounds. MongoDB chose to use "_id" as the document identifier for a reason. Maybe because "id" is somewhat commonly used for other purposes?

An option to change the "id" behavior would be great. I do realize the current behavior is convenient in many cases.

I really like Beanie overall and appreciate all the hard work. I hope this issue can be resolved in a future update. Many thanks to @roman-right and the team!