Doctrine 2 - ORM

Pagination of a SELECT of specific fields results in a RuntimeException

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Can't Fix
  • Affects Version/s: Git Master
  • Fix Version/s: None
  • Component/s: ORM
  • Security Level: All
  • Labels:

Description

When paginating a DQL string which selects specific fields it results in the following error: PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Not all identifier properties can be found in the ResultSetMapping: id'

NOT working: 'SELECT c.id, c.number FROM Application\Entity\Course c'
WORKING: 'SELECT c FROM Application\Entity\Course c'
WORKING: 'SELECT c, c.id, c.number FROM Application\Entity\Course c'

Setting hydration mode to scalar results makes no difference.

Gist to example code and stack trace: https://gist.github.com/d5cd6d0b0ac28e722dd7

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Eberlei added a comment -

First results: This is very complicated to support, the pagination was designed for entity results. I have to check this when I have more time.

Show
Benjamin Eberlei added a comment - First results: This is very complicated to support, the pagination was designed for entity results. I have to check this when I have more time.
Hide
Permalink
dquintard added a comment -

Hi Benjamin,
I can change my code to select entity results (even for hundreds/thousands results).
But for now Pagination is not usable with ResultSetMapping::addScalarResult

Show
dquintard added a comment - Hi Benjamin, I can change my code to select entity results (even for hundreds/thousands results). But for now Pagination is not usable with ResultSetMapping::addScalarResult
Hide
Permalink
Matt Pinkston added a comment - - edited

The reason this error occurs is because the Paginator creates its own ResultSetMapping and relies on the SqlWalker to configure it (see Doctrine\ORM\Query\SqlWalker::walkSelectExpression).

Doctrine will interpret each field in the first example (SELECT c.id, c.number...) as a PathExpression and add it to the result set mapping as a scalar result. This makes it impossible for the paginator to reliably know which field can be considered an identifier.

A quick fix might be to re-write the query to use PartialObjectExpression: SELECT partial c.

{id, number}

...

(edited after a re-read and realization that a custom ResultSetMapping wouldn't cut it)

Show
Matt Pinkston added a comment - - edited The reason this error occurs is because the Paginator creates its own ResultSetMapping and relies on the SqlWalker to configure it (see Doctrine\ORM\Query\SqlWalker::walkSelectExpression). Doctrine will interpret each field in the first example (SELECT c.id, c.number...) as a PathExpression and add it to the result set mapping as a scalar result. This makes it impossible for the paginator to reliably know which field can be considered an identifier. A quick fix might be to re-write the query to use PartialObjectExpression: SELECT partial c. {id, number} ... (edited after a re-read and realization that a custom ResultSetMapping wouldn't cut it)
Hide
Permalink
Benjamin Eberlei added a comment -

Allowing generic+complex pagination on scalar results is impossible for us, closing as can't fix.

Just use LIMITs yourself here or as suggested partial objects.

Show
Benjamin Eberlei added a comment - Allowing generic+complex pagination on scalar results is impossible for us, closing as can't fix. Just use LIMITs yourself here or as suggested partial objects.
Hide
Permalink
Stefano added a comment -

imho this pagination feature is quite useless if we are forced to fetch the complete Entity. Take for example a big table with a lot of data: extracting all the infos will take a lot of time... There should be a way to support the first query type

Show
Stefano added a comment - imho this pagination feature is quite useless if we are forced to fetch the complete Entity. Take for example a big table with a lot of data: extracting all the infos will take a lot of time... There should be a way to support the first query type

People

  • Assignee:
    Benjamin Eberlei
    Reporter:
    Zacharias Luiten
Vote (0)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: