[DDC-2042] Added "targetEntity" to AssociationOverride #633

wants to merge 1 commit into


None yet

8 participants



I needed to override "targetEntity" so I forked Doctrine and applyed it myself. Just after that I found a Ticket [DDC-2042] in your Jira so I added a unit test to and would be more than happy to see this commit get merged in to the main master (at some point ;)).

Cheers, Alex

I will stick around in the #doctrine-dev on Freenode for any questions. My nick there is "fanta".

Keep up the good work.


  • @ORM\Entity
  • @ORM\Table(name="customer")
  • @ORM\AssociationOverrides({
  • @ORM\AssociationOverride(name="products",
  • targetEntity="MyNewProduct"
  • )
  • }) */
@spezifanta spezifanta [DDC-2042] Added "targetEntity" to AssociationOverride
Having the possibility to override "targetEntity" lets the user the
opportunity to change assosciations of sub classes without the need
of changing it's parent class.

Lets say we have the following classes:
- Customer (MappedSuperClass)
-- CustomerDE (Entity)
-- CustomerEN (Entity)
- Product (MappedSuperClass)
-- ProductDE (Entitiy)
-- ProductEN (Entitiy)

Note: All CustomerX entities use the same "customer" table and all
      ProductX entities use the same "product" table. The only differ
      by business logic.

      Simplified example:
      CustomerDE->getFullName() --> "Herr Peter Mueller"
      CustomerEN->getFullName() --> "Mr. P. Mueller"

Example for a sub class called "CustomerUK" (Enitity) which inherits
from "Customer" (MappedSuperClass). Because Customer has a many to many
association to Products, by default CustomerUK would have too. With this
patch this can be changed by applying the following to CustomerUK:

 * @ORM\Entity
 * @ORM\Table(name="customer")
 * @ORM\AssociationOverrides({
 *      @ORM\AssociationOverride(name="products",
 *          targetEntity="MyProductUK"
 *      )
 * })

 Special thanks so Danijel B.

Added test cases for [DDC-2042]


thank you for positing this Pull Request. I have automatically opened an issue on our Jira Bug Tracker for you with the details of this Pull-Request. See the Link:


Doctrine member

HI @spezifanta

During the development of AssociationOverride/AttributeOverride
we discussed about support type changes and we decide does not support this.

IMHO This is a object-orientation mistake.

Could you explain you use case please ?


Yes, I will try to explain my use case.

The key words may be: "optinal sub class inheritance without modifying it's parent".

I have a Customer and Product class. Both are "SuperMappedClass"es.
Customer and Product have a ManyToMany Association.
Now I'll have a CustomerUK, CustomerDE, which both inherit from Customer and a ProductUK and ProductDE, which, of course, inherit from Product.
Those sub classes only differ by business logic.
By default a CustomerUK and CustomerDE would still have relationship to Product.
But I need CustomerUK to point to ProductUK and CustomerDE to point to ProductDE, without, and here comes the "little extra", the need of modifiying the parent suppermapped classes (I dont need/want a discriminator map in my parent classes, as the are in a different bundle and shall not be edited, because they are maintained by different developer)

And this needs to be optional too so that I can have a CustomerNL and CustomerPL both pointing to ProductEU and a CustomerFR that sill uses the default Product.

Does that makes sense?

Anyway, having the possibility to override a targetEntity in a sub class solves this problem for me.

PS: Just to clarify. This is not a "new" feature request (even though Jira started one). I tryed to help and solve [http://www.doctrine-project.org/jira/browse/DDC-2042], which is currently assigned to Benjamin Eberlei and was reported by Charles Rouillon on 26/Sep/12 8:57 AM.

Doctrine member

@spezifanta For this particular use case, I would use a listener on the loadMetadata event rather than making it possible to change the type


@spezifanta Interesting... i can't for the life of my figure out why you need to have this kind of separation.
Shipping, Invoicing, Translation ... all these issues have much easier solutions than this.

I'm curious, please explain :)

Doctrine member

Your inheritance is wrong. The right way would be something like Category -> Customer + Category -> Product, so you can get rid of the DE, EN. For Example your model fails when a UK customer wants to buy in the DE shop for some reason.

@beberlei beberlei closed this Mar 27, 2013

@beberlei Hrhr, it is not that easy to be honest. Or at least I could not find a simpler solution :>

@stof I used a listener before I realized that this would only be a esay patch for doctrine. I found the idea of using a listener on someone's blog, who needed to override targetEntities as well ;)

But I should be absolutely straight with you guys. I have Project ("MyProject") which is a kind of API wrapper of multiples providers. It shall use the composer one day to get updated.
Now I have users that might need to override a entitis' business logic or association's of entities for their needs.


Take a quick note at the targetEntity of OtherCustomerOverrideBundle\MyEntity (on the left, green box)
While overriding it's foobar targetEntity it can use something like this:

$myEntity = $em->find('OtherCustomOverrideBundle\MyEntity', 1);

$myEntity->randomMethod();                        // OtherCustomOverrideBundle\MyEntity (geen box)
$myEntity->getFoobar()->first()->setMyName() ;    // ACustomerOverrideBundle\MyFoobar (orange box)
$myEntity->getFoobar()->first()->otherMethods();  // MyCoreBundle\Foobar (gray box)

Because I don't know my imaginary User1 and UserN, I can't predict which entities' methods the might want to override or what targetEntities they want to use. At same time I can not allow them to modify files in my CoreBundle as this will get updated at some point later (we probably all agree on that changing files in a "vendor" directory is a bad idea).

So by extending the existing AssociationOverride by 5 lines (PR includes extension for XML, YML too) I can now allow Users to inherit my or other's entitie's logic and association in their own entity class without them needing to modify my files, and me without worrying to overwrite their code when rolling out a new release.

I hope I could work out how important the separation of my and my users' entities' logic is and what flexibility this PR would bring to Doctrine 2. I am happy to answer any questions.


I also would like something like this but with a different use case. I have many companies that share a core set of entities. As I am using Symfony, these live in a core bundle, but that's just a convenience of Symfony. The entities in the core bundle have relationships with each other.

Child bundles extend the core entities, and we would like to change the relationships to point to child versions of each entity. Like this:


All entities in the child groups extend from the base group. CompanyAPackage in the orange group and CompanyBpackage in the blue group specify a child entity in their respective relationships.

In this way, I'll be able to share among many companies the core fields and functionality, minimising duplication of code and data.

In PHP, if I set up the child / core relationships as joined entities, I can redeclare the private properties of the child classes and specify different target entities in the child classes; doctrine doesn't throw any errors when I do this. It doesn't work though. The changed relationships don't reflect in the schema and the generated stubs break PHP's type hinting contracts (as I don't think Doctrine expects sub-classes to redeclare properties).

I do get an error (which is good!) when I use a mapped superclass for the base entities, perhaps this exception could also be thrown in the previous situation I mentioned?


In any case, being able to specify a child target entity in a subclass is would satisfy the desired structure perfectly. As it stands, I won't be able to use inheritance to share common functionality.

If it is not possible or considered "bad" to override target entities, I am curious as to why? What are the alternative approaches I could use?


it is very old but i was lead to this case problem recently, is someone find a solution after all this year?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment