[DDC-3855] Inheritance JOINED, left select child entity retrieves not valid object Created: 30/Jul/15  Updated: 30/Jul/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Gregory Pokrovsky Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: DQL, Inheritance, Joined, Query,


Delivery is child of inheritance parent Place. If delivery not set in query, result will have array of PlaceAddress entities, because PlaceAddress is a root alias, but when delivery added to select, then result will contain array of PlaceTypeDelivery but root alias stays PlaceAddress. Is this a bug?

->select(['partial addresses.


','place','partial workday.

{id}','partial delivery.{id}

->from('CommonBundle:PlaceAddress', 'addresses')
->leftJoin("addresses.place", "place", "WITH", "addresses.place = place.id")
->leftJoin("addresses.workday", "workday", "WITH", "workday.address = addresses.id")
->where("place INSTANCE OF CommonBundle:PlaceTypeDelivery")
->andWhere("place.enabled = 1");

[DDC-2140] [GH-512] Added addParameters() to Query and QueryBuilder Created: 13/Nov/12  Updated: 08/Feb/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3, Git Master
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Query,, QueryBuilder

OS X 10.8.2, PHP 5.3.18, Nginx 1.2.4 (php through FPM)


This issue is created automatically through a Github pull request on behalf of jappie:

Url: https://github.com/doctrine/doctrine2/pull/512


This method behaves like setParameters() before version 2.3:
It will add new parameters to the collection, and override any existing positions/names.

It can take a Doctrine\Common\Collections\ArrayCollection with Doctrine\ORM\Query\Parameter objects, as well as a plain array with key/value pairs, as argument.

This will greatly ease the upgrade to Doctrine 2.3, because you only need to perform a project-wide replace of setParameters with addParameters, in stead of going into your code and determine if calls to setParameters are ok or need refactoring.

I've also added unit-tests to maintain integrity.

Comment by Benjamin Eberlei [ 20/Nov/12 ]

A related Github Pull-Request [GH-512] was closed

Comment by Jasper N. Brouwer [ 20/Nov/12 ]

I don't feel strong need to have such an API.
If you want to keep track and merge collection of parameters, all you have to do is create an array (or an ArrayCollection), manipulate the instance and then setParameters at the end.
Unless you give me a stronger argument, this code won't be in. Closing for now.

Hi Guilherme,

I agree that such a method makes less sense in Query, because when you write a DQL string all parameters are known at once. But when using the QueryBuilder you might need different parameters in different cases, so addParameters() becomes useful there.

I guess it's just a convenience method, like IMHO setParameter() is. (You could just do $qb->getParameters()->add())

The main reason for adding the method was, like I said, upgrading to Doctrine 2.3. I've already upgraded all my projects to Doctrine 2.3, so the method is less useful for me now. But it took me a full day to refactor my repositories, because there is no safe way to automate the process. A simple search-and-replace setParameters() to addParameters() would have taken me 5 minutes

I'm content with your decision.
If others find addParameters() useful, I hope they let us know.

Comment by Doctrine Bot [ 08/Feb/14 ]

A related Github Pull-Request [GH-512] was closed:

Generated at Fri Jul 31 23:42:20 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.