-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Problems in the way Zend\Paginator\Adapter\DbSelect count()s #3647
Comments
The resetting of ORDER was included in 2.1.0, can you please test? I need to get a working example of how the joins() affect count(). Is there any way you can reproduce that problem with my Zend_Db-Examples repository? https://github.com/ralphschindler/Zend_Db-Examples |
@ralphschindler I think you misunderstood me. English is not my native language so we might be lost in translation here :) The problem I am stating here is that by not resetting GROUP/HAVING can cause wrong count() results. See my SELECT example above. As for the second part, I am not saying that join()ed columns can affect count(). While I was investigating the issue, I realized that |
@ralphschindler @twmobius I think your problem is (partly) solved here. |
+1, I have this issue too |
Suggested fix: |
Could you have a look at the solution #4641 and let me know if it works for you? |
…com/ralphschindler/zf2 into develop PR #4641 Closes #4590 Closes #3647
Currenty on
Zend\Paginator\Adapter\DbSelect
thecount()
method resets some parts of theZend\Db\Sql\Select
object and leaves others:On ZF1 the same was:
I can understand that not resetting the ORDER doesn't make any difference, but the GROUP makes a huge difference if there is a GROUP BY expression in the Select statement.
Imagine the following query:
SELECT id, MIN(date_added) FROM Table GROUP BY id
count() would have it
SELECT COUNT(1) as c FROM Table GROUP BY id;
thus returning the number of rows per id in the Table (at least in mySQL. Might complain in others)
Similar problem would occur by not resetting HAVING as well.
Finally on a side note
$select->reset(Select::COLUMNS);
does not reset the columns that are a result from join(). Is this expected?The text was updated successfully, but these errors were encountered: