Item10349: SEARCH not affected by limit if pager is on

If you set limit in a SEARCH query, results are not limited if pager is set to on.

-- ArthurClemens - 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.

-- SvenDowideit - 17 Feb 2011

Meaning that limit does not work by design. I think these are 2 different concepts.

-- ArthurClemens - 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.

-- SvenDowideit - 18 Feb 2011

I agree that SearchResultsPagination is vague about limit.

If you have the processing order:

1. Find (create collection, by search query)
2. Sort
3. Trim (for instance by limit)
4. Display (for instance pagination)

Then the limit 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:

%SEARCH{
...
limit="5"
pagesize="5"
pager="off"
}%

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:

%SEARCH{
...
limit="15"
pagesize="10"
pager="on"
}%

... I would expect to see 2 pages: the first with 10 hits, the second with 5 hits.

-- ArthurClemens - 27 Feb 2011

it might not be compaitble with the pre-existnig definition of limit - 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.

legacy sux.

there is a mess wrt groupby (where's that featureProposal?), limit and the pager code. my brain melted, have to let things congeal again.

-- SvenDowideit - 14 Mar 2011

Why do we need to stick to let operate limit per web?

-- ArthurClemens - 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.

-- GeorgeClark

I'm not so convinced we need to deprecate limit... 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 - namely, grouplimit instead of weblimit. I always thought limit should be a limit on the total number of times the format string is applied...

-- PaulHarvey - 03 Apr 2011

I also think we need to keep limit. But it should be a limit for the entire results set, not a limit per web.

-- ArthurClemens - 19 Jun 2011

Commenting is disabled while not logged in