DDC-1040: Using the same named parameter at various places within a DQL query will result in a PHP fatal error #1297

Closed
opened 2026-01-22 13:08:48 +01:00 by admin · 8 comments
Owner

Originally created by @doctrinebot on GitHub (Feb 21, 2011).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user dalvarez:

There are perfectly legitimate situations where the same value needs to be used at various places within a single query (e. g. to compare various versioned artifacts against a common revision number, while joining them). However, specifying the same parameter name twice within a DQL query currently results in a fatal error:

Warning: array_combine(): Both parameters should have an equal number of elements in /var/www/invoiceCreator/src/thirdPartyComponents/doctrine/Doctrine/ORM/Query.php on line 252 Fatal error: Unsupported operand types in /var/www/invoiceCreator/src/thirdPartyComponents/doctrine/Doctrine/ORM/Query.php on line 252

It is possible to work around this by just giving each parameter a unique name. Unfortunately, it becomes an impossibility when using generated DQL statements, e.g. when a correlated subquery is replicated multiple times within the same DQL query.

I can not think of a convincing reason to allow each parameter to appear only once in a query, as the number of parameters could be determined as well by counting the number of unique names rather than simply all names.

Would it be possible to relax the restriction? It would remove a massive burden on dynamically building queries, as currently all parameter names have to be adapted to every single situation, and that would be no longer an issue, if multiple parameters with the same name would be allowed and correctly handled by Doctrine 2.

Apart from the functional requirement, I don't like the crashing effect. If such use is forbidden, it should be officially so (with the documentation at least mentioning the restriction and Doctrine 2 giving an understandable error message when used wrongly, instead of crashing).

Originally created by @doctrinebot on GitHub (Feb 21, 2011). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user dalvarez: There are perfectly legitimate situations where the same value needs to be used at various places within a single query (e. g. to compare various versioned artifacts against a common revision number, while joining them). However, specifying the same parameter name twice within a DQL query currently results in a fatal error: Warning: array_combine(): Both parameters should have an equal number of elements in /var/www/invoiceCreator/src/thirdPartyComponents/doctrine/Doctrine/ORM/Query.php on line 252 Fatal error: Unsupported operand types in /var/www/invoiceCreator/src/thirdPartyComponents/doctrine/Doctrine/ORM/Query.php on line 252 It is possible to work around this by just giving each parameter a unique name. Unfortunately, it becomes an impossibility when using generated DQL statements, e.g. when a correlated subquery is replicated multiple times within the same DQL query. I can not think of a convincing reason to allow each parameter to appear only once in a query, as the number of parameters could be determined as well by counting the number of unique names rather than simply all names. Would it be possible to relax the restriction? It would remove a massive burden on dynamically building queries, as currently all parameter names have to be adapted to every single situation, and that would be no longer an issue, if multiple parameters with the same name would be allowed and correctly handled by Doctrine 2. Apart from the functional requirement, I don't like the crashing effect. If such use is forbidden, it should be officially so (with the documentation at least mentioning the restriction and Doctrine 2 giving an understandable error message when used wrongly, instead of crashing).
admin added the Bug label 2026-01-22 13:08:48 +01:00
admin closed this issue 2026-01-22 13:08:50 +01:00
Author
Owner

@doctrinebot commented on GitHub (Feb 21, 2011):

Comment created by dalvarez:

Currently, I automatically post-process all queries so that all parameters are assigned new (unique) names. This way, even the multiple replicated subqueries within the same DQL query will end up having unique parameter names. While this works, it is clumsy as a general approach.

@doctrinebot commented on GitHub (Feb 21, 2011): Comment created by dalvarez: Currently, I automatically post-process all queries so that all parameters are assigned new (unique) names. This way, even the multiple replicated subqueries within the same DQL query will end up having unique parameter names. While this works, it is clumsy as a general approach.
Author
Owner

@doctrinebot commented on GitHub (Feb 26, 2011):

Comment created by @beberlei:

Works for me, see patch attached.

The error occuring to you is not related to named parameters but to objects as parameters. Can you give a reproducable test-case to fix this?

@doctrinebot commented on GitHub (Feb 26, 2011): Comment created by @beberlei: Works for me, see patch attached. The error occuring to you is not related to named parameters but to objects as parameters. Can you give a reproducable test-case to fix this?
Author
Owner

@doctrinebot commented on GitHub (Feb 26, 2011):

Comment created by dalvarez:

OK, I will see what I can do. I will prepare an example of a working scenario and a non-working scenario, and let you know.

@doctrinebot commented on GitHub (Feb 26, 2011): Comment created by dalvarez: OK, I will see what I can do. I will prepare an example of a working scenario and a non-working scenario, and let you know.
Author
Owner

@doctrinebot commented on GitHub (Feb 26, 2011):

Comment created by dalvarez:

I tried to reduce the non-working query as much as possible to get a schematic idea of what provokes the error.

It seems that queries like this one will break:

`$doctrineQuery = $doctrineEntityManager->createQuery('SELECT a
FROM \persistentData\model\import\A a,
WHERE a.a = :anEntityInstance
AND a.b = :anEntityInstance
AND a.c = :aString');

$doctrineQuery->setParameter('anEntityInstance', $anEntityInstance); // Whatever entity instance
$doctrineQuery->setParameter('aString', $aString); // Some string-valued variable

$doctrineQuery->getResult();`

Note that the first argument is an entity instance, and the second one a string. Both are non-null.

This gives:

Warning: array_combine(): Both parameters should have an equal number of elements in /var/www/invoiceCreator/src/thirdPartyComponents/doctrine/Doctrine/ORM/Query.php on line 252 Fatal error: Unsupported operand types in /var/www/invoiceCreator/src/thirdPartyComponents/doctrine/Doctrine/ORM/Query.php on line 252

This is a basic form of a working scenario (all parameters have unique names):

`$doctrineQuery = $doctrineEntityManager->createQuery('SELECT a
FROM \persistentData\model\import\A a,
WHERE a.a = :anEntityInstance1
AND a.b = :anEntityInstance2
AND a.c = :aString');

$doctrineQuery->setParameter('anEntityInstance1', $anEntityInstance); // Whatever entity instance
$doctrineQuery->setParameter('anEntityInstance2', $anEntityInstance); // Whatever entity instance
$doctrineQuery->setParameter('aString', $aString); // Some string-valued variable

$doctrineQuery->getResult();`

@doctrinebot commented on GitHub (Feb 26, 2011): Comment created by dalvarez: I tried to reduce the non-working query as much as possible to get a schematic idea of what provokes the error. It seems that queries like this one will break: `$doctrineQuery = $doctrineEntityManager->createQuery('SELECT a FROM \persistentData\model\import\A a, WHERE a.a = :anEntityInstance AND a.b = :anEntityInstance AND a.c = :aString'); $doctrineQuery->setParameter('anEntityInstance', $anEntityInstance); // Whatever entity instance $doctrineQuery->setParameter('aString', $aString); // Some string-valued variable $doctrineQuery->getResult();` Note that the first argument is an entity instance, and the second one a string. Both are non-null. This gives: Warning: array_combine(): Both parameters should have an equal number of elements in /var/www/invoiceCreator/src/thirdPartyComponents/doctrine/Doctrine/ORM/Query.php on line 252 Fatal error: Unsupported operand types in /var/www/invoiceCreator/src/thirdPartyComponents/doctrine/Doctrine/ORM/Query.php on line 252 This is a basic form of a working scenario (all parameters have unique names): `$doctrineQuery = $doctrineEntityManager->createQuery('SELECT a FROM \persistentData\model\import\A a, WHERE a.a = :anEntityInstance1 AND a.b = :anEntityInstance2 AND a.c = :aString'); $doctrineQuery->setParameter('anEntityInstance1', $anEntityInstance); // Whatever entity instance $doctrineQuery->setParameter('anEntityInstance2', $anEntityInstance); // Whatever entity instance $doctrineQuery->setParameter('aString', $aString); // Some string-valued variable $doctrineQuery->getResult();`
Author
Owner

@doctrinebot commented on GitHub (Apr 3, 2011):

Comment created by @beberlei:

Fixed.

@doctrinebot commented on GitHub (Apr 3, 2011): Comment created by @beberlei: Fixed.
Author
Owner

@doctrinebot commented on GitHub (Apr 3, 2011):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Apr 3, 2011): Issue was closed with resolution "Fixed"
Author
Owner

@doctrinebot commented on GitHub (Apr 5, 2011):

Comment created by dalvarez:

Great, thanks.

@doctrinebot commented on GitHub (Apr 5, 2011): Comment created by dalvarez: Great, thanks.
Author
Owner

@doctrinebot commented on GitHub (Dec 13, 2015):

Imported 1 attachments from Jira into https://gist.github.com/114f4860e989197c35e3

@doctrinebot commented on GitHub (Dec 13, 2015): Imported 1 attachments from Jira into https://gist.github.com/114f4860e989197c35e3 - [10946_ddc1040.diff](https://gist.github.com/114f4860e989197c35e3#file-10946_ddc1040-diff)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#1297