[BUG] After first_or_none of class FindMany, limit_number == 1 remains

[eac0de]

Describe the bug and reproduce and expected behavior
After first_or_none of class FindMany, limit_number == 1 remains.
So

  requests = RequestModel.find() # I have 3 requests 
  first_request = await requests.first_or_none() # Return first request
  requests_list = requests.to_list() # In my opinion It must to return 3 requests, but returns 1 after first_or_none because first_or_none  assigns limit_number == 1

It's very unobvious!

Solution

async def first_or_none(self) -> Optional[FindQueryResultType]:
    """
    Returns the first found element or None if no elements were found
    """
    existing_limit_number = self.limit_number
    res = await self.limit(1).to_list()
    self.limit_number = existing_limit_number
    if not res:
        return None
    return res[0]

[staticxterm]

Hi @eac0de, this is the expected behavior for this method. If there are 3 documents, it shall return the first one and limit the response to that single document that matches some search criteria.
This is mentioned in the documentation:
https://beanie-odm.dev/tutorial/finding-documents/#finding-documents
Is there something not clear in documentation you would like to propose to be changed?

[eac0de]

Hi @eac0de, this is the expected behavior for this method. If there are 3 documents, it shall return the first one and limit the response to that single document that matches some search criteria.
This is mentioned in the documentation:
https://beanie-odm.dev/tutorial/finding-documents/#finding-documents
Is there something not clear in documentation you would like to propose to be changed?

Hi!
The documentation says that: "It returns the first found document or None, if no documents were found."

There is nothing written there about changing the object FindMany and when it is reused, bugs are created.This is a very inconvenient and non-obvious solution

[staticxterm]

Apologies for misreading your example.
Indeed you're right about that, and it shouldn't mutate 'self' but return a new result object.
Will look more into this.

[staticxterm]

Hi again @eac0de, good find. I like your proposed fix, would you mind opening a PR for this please?

[eac0de]

Hi again @eac0de, good find. I like your proposed fix, would you mind opening a PR for this please?

Hi, again)
Yes, sure)