Development

#487 (sfPropelPager, Criteria with addGroupByColumn, gives pager the wrong count for total and pages)

You must first sign up to be able to contribute.

Ticket #487 (reopened defect)

Opened 3 years ago

Last modified 1 month ago

sfPropelPager, Criteria with addGroupByColumn, gives pager the wrong count for total and pages

Reported by: synace Assigned to: fabien
Priority: major Milestone:
Component: sfPropelPlugin Version: 1.2.5
Keywords: sfpager sfpropelpager group addgroupbycolumn cleargroupbycolumns Cc:
Qualification: Unreviewed

Description

sfPropelPager::init

contains: (line 58?)

$cForCount->clearGroupByColumns();

Which means that if your criteria contains any group clauses, they'll be removed, and the 'count' will be on ALL results (not the total after grouping).

So, the result count and page count will be wrong, causing the pagination to be wrong.

Removing this line seems to be the proper fix.

What was purpose of clearGroupColumns in the sfPager that was imported when the symfony svn was created?

Change History

06/16/06 09:46:47 changed by fabien

  • milestone changed from 0.6.3 to 1.0.0.

08/10/06 00:40:18 changed by synace

  • status changed from new to closed.
  • resolution set to fixed.

(In [1654]) (fixes #487), fabien please review original purpose of clearGroupByColumns

08/10/06 00:41:16 changed by synace

  • status changed from closed to reopened.
  • resolution deleted.

(fixed in [1654])

08/21/06 10:48:55 changed by fabien

  • status changed from reopened to closed.
  • resolution set to fixed.

(In [1677]) fixed sfPropelPager, Criteria with addGroupByColumn, gives pager the wrong count for total and pages (closes #487 - patch from synace)

08/23/06 11:03:39 changed by francois

  • status changed from closed to reopened.
  • resolution deleted.

08/23/06 12:50:12 changed by fabien

  • status changed from reopened to closed.
  • resolution set to fixed.

(In [1758]) reverted r1677 (closes #487)

02/11/08 03:52:26 changed by 3mlabs

  • priority changed from major to minor.
  • version changed from 0.6.2 to 1.0.11.
  • component set to askeet.
  • qualification set to Unreviewed.
  • milestone changed from 1.0.0 to 1.0.12.

Why was reverted? This line still makes the pager to be wrong

04/10/08 21:04:48 changed by joethong

  • priority changed from minor to major.
  • status changed from closed to reopened.
  • resolution deleted.

Hi, this is a major issue for me as well. Is this going to be fixed? Why couldn't we just remove the line as was suggested by synace?

In the first post of this thread http://www.symfony-project.org/forum/index.php?t=rview&goto=10731&th=2450#msg_10731 vonLeeb said "But gouping is needed in parent<->children relationship when you want to count children of each of your parent records and present it." What does this mean?

Regards Joe Thong

04/30/08 19:33:20 changed by FabianLange

  • milestone deleted.

05/13/08 14:43:22 changed by FabianLange

  • component changed from askeet to other.

08/14/08 22:12:02 changed by dlefkon

  • cc set to dlefkon@gmail.com.

Had this problem. Fixed by changing '$distinct = false' to '$distinct = true' overriding the doCount() function in the peer class.

David Lefkon

08/22/08 15:53:10 changed by dlefkon

May also be necessary (e.g. if not joining other tables) to override the default count_distinct column in the peer class:

const COUNT_DISTINCT = 'COUNT(DISTINCT lead.CODE)';

where 'lead' is the class and 'CODE' is the field name that want to group by.

02/27/09 13:06:58 changed by caezar

  • cc deleted.
  • version changed from 1.0.11 to 1.2.4.
  • component changed from other to sfPropelPlugin.

This is really a bug. Since BasePeer::doCount method checks if criteria has groub by columns and able to perform correct count under this circumstances - the clearGroupByColumns is not needed here. May be somebody from core team can accept this as a bug? I don't think it'll be a problem for anyone to prepare patch.

03/31/09 03:31:04 changed by vitriolix

  • version changed from 1.2.4 to 1.2.5.

I'm still seeing this in 1.2.5, any particular reason this is still not fixed 3 years after opening? This makes the pager pretty useless for situations where we have complex queries.

Is this blocked on a bug upstream in Propel itself? If so, can we get a bug number in their tracker here so we can follow up on that?

05/28/09 16:14:15 changed by istaveren

I agree that this is a bug.

The solution would be just to remove line 43

public function init() {

$hasMaxRecordLimit = ($this->getMaxRecordLimit() !== false); $maxRecordLimit = $this->getMaxRecordLimit();

$cForCount = clone $this->getCriteria(); $cForCount->setOffset(0); $cForCount->setLimit(0);

// $cForCount->clearGroupByColumns();

$count = call_user_func(array($this->getClassPeer(), $this->getPeerCountMethod()), $cForCount);

The Sensio Labs Network

Since 1998, Sensio Labs has been promoting the Open-Source software movement by providing quality web application development, training, consulting, and supporting several large Open-Source projects.