Remove default limit of 1000 from QuerystringSearch

[wesleybl]

Previously, QuerystringSearch imposed a hardcoded limit=1000 on all queries, even when the user did not specify a limit. This caused unexpected truncation of results.

Now the limit parameter is only passed to querybuilder when explicitly provided in the request data.

Closes #1955

---

📚 Documentation preview 📚: https://plonerestapi--1963.org.readthedocs.build/

[mister-roboto]

@wesleybl thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

[davisagli]

The default limit is there for a reason, to prevent accidental long-running requests that return too many results. I would rather keep the limit but fix the response so that it reports the total result count correctly.

[wesleybl]

@davisagli But isn't that hide the results?

[davisagli]

@wesleybl Yes, unless you specifically ask for more. That's intentional. (But setting items_total to the limit, instead of the actual total, is not intentional.)

[wesleybl]

Yes, unless you specifically ask for more. That's intentional.

@davisagli But the frontend doesn't know how many records exist, so it can't pass a value. This limits access to the records the user might want. And with pagination, it will never return 1000 items.

Note that a normal search doesn't have this limit: https://github.com/plone/plone.restapi/blob/main/src/plone/restapi/search/handler.py

[wesleybl]

@jenkins-plone-org please run jobs

[wesleybl]

But setting items_total to the limit, instead of the actual total, is not intentional.

If we change this, it will cause the pagination to return pages that are not reachable, causing an error. Here's the PR that inserted this:

plone/plone.app.querystring#17

[wesleybl]

@davisagli So what's your suggestion for fixing this problem? Could we create a setting in Volto to increase this limit? But honestly, I don't think that would be the best solution.

[davisagli]

For one thing, we should make sure that the batch class used for pagination is not broken by having an actual_result_count that is higher than the limit. The whole point of the catalog returning actual_result_count is to provide this information.

I need to take a closer look at all the parts of this. It may be that we can remove the default limit but I need to check some things.

[wesleybl]

@davisagli I still don't quite understand your concern. Are you worried that "accidentally" more than 1000 items might be returned? Would that be through a call without parameters? Can you give an example of a call that "accidentally" returns multiple items? Today we have a default value for b_size:

https://github.com/plone/plone.restapi/blob/main/src/plone/restapi/services/querystringsearch/get.py#L38

So calls without parameters won't return 1000 items, even without the limit. To return 1000, we would have to pass b_size=1000. In my opinion, this is not accidental.