Different indexes in some iterations of a DQL query result #6002

New Issue

admin · 2026-01-22T15:24:33+01:00

admin commented

2026-01-22 15:24:33 +01:00

Originally created by @enumag on GitHub (Jun 28, 2018).

Bug Report

Q	A
BC Break	not sure
Version	2.6.1

I have no idea if this was broken recently or have always been like that so I can't answer if it is a BC break or not.

Summary

Different indexes when iterating over a query.

Sadly I don't have the time to create a failing test case for this. I realize that you're unlikely to find and fix the bug based on this report unless you know the internals well enough to immediately know what's the problem. The bug is a low priority for me so I can't spend the time needed for a better report. Feel free to simply close this issue.

How to reproduce

I have a query like this:

		return $this->entityManager->createQueryBuilder()
			->select('fi, COALESCE(SUM(pa.bigIntAmount), 0)')
			->distinct()
            // some joins, wheres, group by, having
            // no idea what is and what isn't related to this bug

Then I iterate over it like this:

foreach ($builder->getQuery()->iterate() as $row) {
   // ...
}

Current behavior

In the loop above the $row has different structure in some iterations.

Sometimes it looks like this:

$row = [
  0 => [
    0 => // the 'fi' entity
    1 => // the coalesce-sum field
  ]
]

Other times it looks like this:

$row = [
  0 => [
    0 => // the 'fi' entity
  ],
  1 => [
    1 => // the coalesce-sum field
  ]
]

EDIT: And in one case it even looked like this:

$row = [
  0 => [
    0 => // the 'fi' entity
  ],
  2 => [
    1 => // the coalesce-sum field
  ]
]

Basically the entity is always at $row[0][0] while the coalesce-sum field is sometimes in $row[0][1] and other times in $row[1][1].

Expected behavior

The rows should always have the same structure but I'm not sure which structure is correct. Why are the values nested to the second level anyway? Personally I'd simply expect this:

$row = [
  0 => // the 'fi' entity
  1 => // the coalesce-sum field
]

Originally created by @enumag on GitHub (Jun 28, 2018). ### Bug Report | Q | A |------------ | ------ | BC Break | not sure | Version | 2.6.1 I have no idea if this was broken recently or have always been like that so I can't answer if it is a BC break or not. #### Summary Different indexes when iterating over a query. Sadly I don't have the time to create a failing test case for this. I realize that you're unlikely to find and fix the bug based on this report unless you know the internals well enough to immediately know what's the problem. The bug is a low priority for me so I can't spend the time needed for a better report. Feel free to simply close this issue. #### How to reproduce I have a query like this: ```php return $this->entityManager->createQueryBuilder() ->select('fi, COALESCE(SUM(pa.bigIntAmount), 0)') ->distinct() // some joins, wheres, group by, having // no idea what is and what isn't related to this bug ``` Then I iterate over it like this: ```php foreach ($builder->getQuery()->iterate() as $row) { // ... } ``` #### Current behavior In the loop above the `$row` has different structure in some iterations. Sometimes it looks like this: ``` $row = [ 0 => [ 0 => // the 'fi' entity 1 => // the coalesce-sum field ] ] ``` Other times it looks like this: ``` $row = [ 0 => [ 0 => // the 'fi' entity ], 1 => [ 1 => // the coalesce-sum field ] ] ``` EDIT: And in one case it even looked like this: ``` $row = [ 0 => [ 0 => // the 'fi' entity ], 2 => [ 1 => // the coalesce-sum field ] ] ``` Basically the entity is always at `$row[0][0]` while the coalesce-sum field is sometimes in `$row[0][1]` and other times in `$row[1][1]`. #### Expected behavior The rows should always have the same structure but I'm not sure which structure is correct. Why are the values nested to the second level anyway? Personally I'd simply expect this: ``` $row = [ 0 => // the 'fi' entity 1 => // the coalesce-sum field ] ```

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6002