QueryBuilder::getQuery does not clone parameters, is this intended or a bug? #6222

New Issue

admin · 2026-01-22T15:29:09+01:00

admin commented

2026-01-22 15:29:09 +01:00

Originally created by @datadestroyd on GitHub (Apr 15, 2019).

Originally assigned to: @Ocramius on GitHub.

Bug Report

Q	A
Version	2.6.3

Summary

QueryBuilder::getQuery does not deep clone the parameters. I am unsure whether this is intended behavior or a bug. The docs don't mention it. However, I find it very counterintuitive.

Current behavior

When calling getQuery on a QueryBuilder, the parameters are copied into the Query instance. However, subsequently modifying parameters on the builder, e.g. to create another similar query, also modify the parameters in the previous Query instance.

How to reproduce

$builder = $em->createQueryBuilder()
  ->from('SomeEntity', 'e')
  ->select('e')
  ->where('e.someProperty = :param')
  ->setParameter('param', 'foo');

$queryA = $builder->getQuery();

$builder->setParameter('param', 'bar');

$queryB = $builder->getQuery();

// $queryA->getParameter('param')->getValue() === $queryB->getParameter('param')->getValue() === 'bar'

Expected behavior

$queryA->getParameter('param')->getValue() should return 'foo', not 'bar'.

Originally created by @datadestroyd on GitHub (Apr 15, 2019). Originally assigned to: @Ocramius on GitHub. ### Bug Report | Q | A |------------ | ------ | Version | 2.6.3 #### Summary `QueryBuilder::getQuery` does not deep clone the parameters. I am unsure whether this is intended behavior or a bug. The docs don't mention it. However, I find it very counterintuitive. #### Current behavior When calling `getQuery` on a `QueryBuilder`, the parameters are copied into the `Query` instance. However, subsequently modifying parameters on the builder, e.g. to create another similar query, also modify the parameters in the previous `Query` instance. #### How to reproduce ```php $builder = $em->createQueryBuilder() ->from('SomeEntity', 'e') ->select('e') ->where('e.someProperty = :param') ->setParameter('param', 'foo'); $queryA = $builder->getQuery(); $builder->setParameter('param', 'bar'); $queryB = $builder->getQuery(); // $queryA->getParameter('param')->getValue() === $queryB->getParameter('param')->getValue() === 'bar' ``` #### Expected behavior `$queryA->getParameter('param')->getValue()` should return `'foo'`, not `'bar'`.

admin added the Can't Fix Question labels 2026-01-22 15:29:09 +01:00

admin closed this issue

2026-01-22 15:29:09 +01:00

admin commented

2026-01-22 15:29:09 +01:00

@Ocramius commented on GitHub (Apr 15, 2019):

This is very much expected, since there is no guarantee that parameters are cloneable in first place. I agree that cloning the ParameterCollection would be a good idea, but it is only applicable for 3.x: consider sending a patch directly.

Closing here meanwhile.

@Ocramius commented on GitHub (Apr 15, 2019): This is very much expected, since there is no guarantee that parameters are cloneable in first place. I agree that cloning the `ParameterCollection` would be a good idea, but it is only applicable for `3.x`: consider sending a patch directly. Closing here meanwhile.

admin commented

2026-01-22 15:29:10 +01:00

@datadestroyd commented on GitHub (Apr 16, 2019):

The collection is already being cloned. I am talking about the Parameter instances inside that collection. I didn't mean that the values themselves should be cloned. Like you said, that is not necessarily possible.

So basically what I meant was that $queryA->getParameter('param') should not return the same Parameter instance as $queryB->getParameter('param'). Just a thought.

@datadestroyd commented on GitHub (Apr 16, 2019): The collection is already being cloned. I am talking about the `Parameter` instances inside that collection. I didn't mean that the values themselves should be cloned. Like you said, that is not necessarily possible. So basically what I meant was that `$queryA->getParameter('param')` should not return the same `Parameter` instance as `$queryB->getParameter('param')`. Just a thought.

admin referenced this issue

2026-01-22 16:05:47 +01:00

[PR #6222] Fix invalid joinColumn in ClassMetadata::associationMappings #9902

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#6222