beanie 'revision_id' field is added to Document when used as response

First of all, thank you for creating this library. I just started using it with FastAPI and it seems to be a good match. However, I noticed that when a Document is used as response_model in FastAPI, a revision_id field is returned.

Like in the example below from the beanie_fastapi_demo with the beanie version set to 1.7.0.

This code (I only included the relevant parts):

class Note(Document):
    title: str
    text: Optional[str]
    tag_list: List[Tag] = []


@notes_router.post("/notes/", response_model=Note)
async def create_note(note: Note):
    await note.create()
    return note

When called with

curl -X 'POST' \
  'http://127.0.0.1:10001/v1/notes/' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "title": "my test",
  "text": "with some text",
  "tag_list": []
}'

Will return:

{
  "_id": "617ebbc46c9ce4b67d333f4f",
  "revision_id": null,
  "title": "my test",
  "text": "with some text",
  "tag_list": []
}

Looking through the code, and using git blame I think revision_id was introduced in 1.6.0. The documentation on this feature is sparce, so I'm not really sure what to do with this field. In any case I would like to hide the field in the serialized output and schema, as I don't want it to be part of the api schema. So far, I have not found a way to do this, other than creating a specific (pydantic) model like so:

class NoteResp(BaseModel):
    id: PydanticObjectId
    title: str
    text: Optional[str]
    tag_list: List[Tag] = []

class Note(Document, NoteResp):
    pass

@notes_router.post("/notes/", response_model=NoteResp)
async def create_note(note: Note):
    await note.create()
    return NoteResp(**note.dict())

However this realy feels like a workaround. Maybe there is a way to 'disable' the revision_id field I haven't found yet?

Oct 31 '21 16:10 MovingEarth

Hey! Thank you for the issue. This is a bug - fixed in the 1.7.1. Please, update

Nov 02 '21 16:11 roman-right

I tried 1.7.1 and revision_id has been removed from the output. However, It is still in the schema, marked as hidden, and thus also appears in the example response Is there anything we can do about that? Because now andybody who creates an api will have to explain to the user of the api what the purpose of revision_id.

Nov 02 '21 20:11 MovingEarth

Should be hidden there too now. Pls check 1.7.2

Nov 03 '21 18:11 roman-right

Yes, 1.7.2 totally resolves the visibility issue in output and schema. Thanks for your efforts.

More on a sidenote: I noticed the field can still be 'used', so it is as the code calls it "hidden". So, when beanie is used in an API (say using FastAPI) the user of the api can still use the revision_id (although, if it is later no longer supported, not complain when it is removed as it is an undocumented api feature). When the developer of the API wants to use the revision_id in the api, it has to be "un-hiden" (at this point, I would not know how, maybe by defining the field in my model?)

It might be completely against the philosophy of beanie (sorry I have not read the code yet), but it might be worth having these kind of features controlled from a config class of some sort like you see in other frameworks. So the developer could write something like the code below to enable the revision_id:

class Note(Document):
    
    title: str
    text: Optional[str]

    class Config:
        use_revision_id = True

The idea being, by default "revision_id" is not used (not hidden, but really not used), but can be enabled using the config class.

This also gives you an opportunity to add new features in the future, which (by default) do not break an existing api generated by beanie (by adding of removing fields) and still allow the developer to adopt new features when needed / wanted.

Nov 08 '21 05:11 MovingEarth

Hey. This make sense, but implementation could be tricky, as it is a pydantic field under the hood. I'll try to not use this field if the config is turned of soon.

Also, this feature is finally released. The doc about this could be found here: https://roman-right.github.io/beanie/tutorial/revision/

Nov 29 '21 18:11 roman-right

So this issue is a bit tricky. Its being caused by FastAPIs naive method of creating its document. I had to roll my own to get a functioning output. It was pretty easy to do I can see how portable to it is and if it is something I can port. The only issue becomes we would need to pin the pydantic version because its not code that is part of the API spec that needs to get replaced. Pydantic has a pretty slow release schedule so it is not that bad to do TBH.