save has no return value

[hgalytoby]

Prior to version 1.17.0, there was a return value when using "save".

In version 1.18.0, however, there is no return value when using "save".

This change in behavior may cause errors in modules that expect a return value from "save".

Is it correct for there to be no return value now?

import asyncio

from beanie import init_beanie, Document
from motor.motor_asyncio import AsyncIOMotorClient


class Sample(Document):
    name: str


async def init():
    client = AsyncIOMotorClient(
        "mongodb://root:12345678@localhost:27017/"
    )
    await init_beanie(database=client.db_name, document_models=[Sample])


async def main():
    await init()
    instance = await Sample.find_one()
    if not instance:
        await Sample(name='test').save()
    for key, value in {'name': '123'}.items():
        setattr(instance, key, value)
    r = await instance.save()
    print(r)


if __name__ == '__main__':
    asyncio.run(main())

[Abashinos]

Doesn't look like a bug imo (type hint of None must be deliberate), albeit an unexpected breaking change in a minor version update (supposing Beanie adheres to SemVer convention for release versions).
Probably worth to just return self from the save() method to retain backward compatibility in 1.18.0 release proper.
WDYT, @roman-right ?

[hgalytoby]

I don't think it's a bug, I just want to confirm if this is correct.

This way, other module authors who use 'beanie' and rely on the return value of 'save()' will be better able to decide whether or not they need to modify their code.

[roman-right]

Hello.
I can explain. In 1.17 save used insert and replace under the hood. Both return the instance. In 1.18 it uses update, which returns None. But in general yes, I see this inconsistency. Probably it would be better to return the instance in all the changing methods. I'll think about this and it will be fixed.

@Abashinos, about semver :) I do breaking changes in minor versions, as I reserve the major version for global architecture changes (IDK, using something instead of Pydantic or complete api rework using another approach for the collection management. Something like this), but I mention them in the changelog each time. The problem is the lib is too big to predict all the breaking changes (This one is a good example ). I'm thinking about switching to calver even, as it is simpler to manage.