Difference between revisions of "Issue:False result count"
(New page: {{Issue |Type = Bug |Extension = DPL |Version = 1.4.3 |Description = result count is affected by the max result limit of DPL |Status = open }} == Problem == It see...) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
|Version = 1.4.3 | |Version = 1.4.3 | ||
|Description = result count is affected by the max result limit of DPL | |Description = result count is affected by the max result limit of DPL | ||
| − | |Status = | + | |Status = answered / discussion |
}} | }} | ||
| Line 15: | Line 15: | ||
Cheers, --[[User:Dmb|Dmb]] 14:27, 14 September 2007 (CEST) | Cheers, --[[User:Dmb|Dmb]] 14:27, 14 September 2007 (CEST) | ||
| + | == Reply == | ||
| + | |||
| + | You are right. But I would have to do a separate "select count()" statement only to catch these constellations. This would put extra complexity and runtime cost to every DPL query. I doubt that this is a good cost benefit ratio. So I tend to leave it as it is. You could, however, put a #if statement around %PAGES% replacing '500' by '500 or more'. Or should I add the "or more" phrase automatically when the count limit is hit? [[User:Gero|Gero]] 23:44, 19 October 2007 (CEST) | ||
== Reply == | == Reply == | ||
| + | |||
| + | With version 1.5.2 I changed the implementation of count/offset to use SQL directly. Now DPL behaves as any SQL query would: If a limit is set the returned number of records will equal that limit (provided there more matching records in the database). Executing a second query with changed offset will deliver the next "portion" and so on. Currently there is no such thing like SELECT COUNT(*) from ... in DPL. | ||
| + | |||
| + | But you could write a recursive DPL query which fetches all portions and adds up the %PAGES%. | ||
| + | :[[User:Gero|Gero]] 07:19, 3 November 2007 (CET) | ||
Latest revision as of 07:19, 3 November 2007
| Description: | result count is affected by the max result limit of DPL |
| Extension / Version: | DPL / 1.4.3 |
| Type / Status: | Bug / answered / discussion |
Problem
It seems like %PAGES% should not be affected by $wgDPL2MaxResultCount, but it is. For example, http://pdbwiki.info/index.php/Talk:Main_Page
The DPL on that page reports 500 articles in the category. Any way that %PAGES% could specifically get its data from the database without hitting $wgDPL2MaxResultCount ? It seems that the idea of $wgDPL2MaxResultCount is quite contrary to its behaviour wrt. %PAGES%.
Cheers, --Dmb 14:27, 14 September 2007 (CEST)
Reply
You are right. But I would have to do a separate "select count()" statement only to catch these constellations. This would put extra complexity and runtime cost to every DPL query. I doubt that this is a good cost benefit ratio. So I tend to leave it as it is. You could, however, put a #if statement around %PAGES% replacing '500' by '500 or more'. Or should I add the "or more" phrase automatically when the count limit is hit? Gero 23:44, 19 October 2007 (CEST)
Reply
With version 1.5.2 I changed the implementation of count/offset to use SQL directly. Now DPL behaves as any SQL query would: If a limit is set the returned number of records will equal that limit (provided there more matching records in the database). Executing a second query with changed offset will deliver the next "portion" and so on. Currently there is no such thing like SELECT COUNT(*) from ... in DPL.
But you could write a recursive DPL query which fetches all portions and adds up the %PAGES%.
- Gero 07:19, 3 November 2007 (CET)
