mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
Pagination: countQuery overrides existing ResultSetMapping #5360
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nikolajlovenhardt on GitHub (Dec 22, 2016).
Hello,
I have an issue regarding the count method in the doctrine paginator.
Snippet
The issue
The
getCountQuerymethod inDoctrine\ORM\Tools\Pagination\Paginatoroverrides the result mapping in line 251. It is not appropriate because it overwrites the existing result mapping, and therefore in my case returns a count of 0.So the Paginator has results, but the count is zero.
I'm not sure how to fix this, because the
getResultMappingmethod in the Query is private.Thank you in advance
@Ocramius commented on GitHub (Dec 23, 2016):
Linking logic that overwrites the mappings
@nikolajlovenhardt I don't see any custom mappings in your case? Can you make this an isolated test case?
@nikolajlovenhardt commented on GitHub (Dec 23, 2016):
@Ocramius
No you are right - I don't add any custom mappings. But when debugging I found out that changing
$rsm = new ResultSetMapping();into$rsm = $countQuery->getResultMapping()seemed to be fixing the problem. But that's not possible since the getResultMapping method is protected.I've made an example below
https://gist.github.com/nikolajlovenhardt/dcaee906027a57e8bb0ee4f8f29c8816
@Ocramius commented on GitHub (Dec 23, 2016):
I understand the issue even less now, or the issue description doesn't
reflect the test that you linked.
I'll try running the test locally though.
On 23 Dec 2016 08:55, "Nikolaj Løvenhardt Petersen" <
notifications@github.com> wrote:
@Ocramius commented on GitHub (Dec 23, 2016):
Converted into a failing test case in https://github.com/doctrine/doctrine2/pull/6194
@Ocramius commented on GitHub (Dec 23, 2016):
I applied the patch to #6194, but exposing the resultset mapping is a no-go from here.
Will need an alternate approach instead, or checking why the new mapping doesn't fit.