Difference between revisions of "Issue:False result count"

From FollowTheScore
Jump to: navigation, search
(Problem)
 
(One intermediate revision 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      = open
+
  |Status      = answered / discussion
 
}}
 
}}
  
Line 20: Line 20:
  
 
== 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)