Current State: Needs Developer
Released In: n/a
Target Release: n/a
If you set
query, results are not limited if
is set to
- 13 Feb 2011
yes. mmm. I'm pretty sure I coded the pagesize to replace the limit mess - as the per-web calculation doesn't work when you do non-web-page counting
not to say that this is optimal, but limit has a pretty disgusting definition.
- 17 Feb 2011
does not work by design. I think these are 2 different concepts.
- 17 Feb 2011
yes, they are different - but due to how limit was implemented years ago, they are incompatible. Mind you, the real issue is that the feature proposal didn't work out a way to resolve this issue without causing more
so I'd suggest you define how you think is ought to work (in a new feat req) and see if we can come to a common middle.
- 18 Feb 2011
I agree that SearchResultsPagination
is vague about limit.
If you have the processing order:
- Find (create collection, by search query)
- Trim (for instance by limit)
- Display (for instance pagination)
param would reduce the number of items displayed using the pager.
It can be simulated with this. If you want a limit of 5, write:
This gives a result set of 5 items without pager.
Of course it is different if I want a limit that exceeds my pagesize. I cannot simulate this, but if I would write:
... I would expect to see 2 pages: the first with 10 hits, the second with 5 hits.
- 27 Feb 2011
not be compaitble with the pre-existnig definition of
- which is to limit the number of results per web :/
so limit=5 pagesize=5 would only not show a pager if
there is only one web, or only a max of 5hits.
there is a mess wrt
(where's that featureProposal?),
code. my brain melted, have to let things congeal again.
- 14 Mar 2011
Why do we need to stick to let operate limit per web?
- 14 Mar 2011
Changing the impact of limit will break existing applications. Any search that is written to show the "first n topics per web" needs the old definition. Maybe we need to deprecate limit, and add a "weblimit" and "hitlimit" or something similar, so the definitions are clear.
I'm not so convinced we need to deprecate
... I would prefer that we didn't, actually. Obviously the pager is the right way to go for wiki-apps, it just seems odd to delete skip/limit when there's so much out there (in coder-land) that uses these parameter names the same way.
As for "sub"-limits, let's keep it consistent with AddDollarTotalToFormattedSearch
. I always thought
should be a limit on the total number of times the
string is applied...
- 03 Apr 2011
I also think we need to keep
. But it should be a limit for the entire results set, not a limit per web.
- 19 Jun 2011