One-To-Many Bidirectional: Bug in doctrine:generate:entities or in docs #5738

New Issue

admin · 2026-01-22T15:16:01+01:00

admin commented

2026-01-22 15:16:01 +01:00

Originally created by @ThomasLandauer on GitHub (Oct 11, 2017).

Somehting is wrong in the following scenario - I'm just not sure if it's a bug in doctrine:generate:entities or in the docs ;-)

When I set up two entities as in this example: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html#one-to-many-bidirectional
...and then run doctrine:generate:entities, I get this in Product.php:

public function addFeature(\AppBundle\Entity\Feature $feature)

However, when I do $product->addFeature($feature);, the Feature is not persisted correctly: The field feature.product_id is not populated.

This is in accordance with the docs (same link as above):

This is because the many side in a one-to-many association holds the foreign key, making it the owning side.

So the question is: Why is public function addFeature generated at all, if it's useless??

Or am I doing it wrong and it isn't useless?

Originally created by @ThomasLandauer on GitHub (Oct 11, 2017). Somehting is wrong in the following scenario - I'm just not sure if it's a bug in `doctrine:generate:entities` or in the docs ;-) When I set up two entities as in this example: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html#one-to-many-bidirectional ...and then run `doctrine:generate:entities`, I get this in `Product.php`: ```php public function addFeature(\AppBundle\Entity\Feature $feature) ``` However, when I do `$product->addFeature($feature);`, the Feature is not persisted correctly: The field `feature.product_id` is not populated. This is in accordance with the docs (same link as above): > This is because the many side in a one-to-many association holds the foreign key, **making it the owning side.** So the question is: Why is `public function addFeature` generated at all, if it's useless?? Or am I doing it wrong and it isn't useless?

admin commented

2026-01-22 15:16:04 +01:00

@mateuszsip commented on GitHub (Oct 14, 2017):

Think that this section will explain it.

@mateuszsip commented on GitHub (Oct 14, 2017): Think that [this section](http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-associations.html#transitive-persistence-cascade-operations) will explain it.

admin commented

2026-01-22 15:16:04 +01:00

@ThomasLandauer commented on GitHub (Oct 14, 2017):

@kejwmen Yeah, I know that section, cause I wrote it ;-) https://github.com/doctrine/doctrine2/pull/6219

If that's the only reason why addFeature() is generated automatically, then I'd say it should only be created if cascade:persist is set.

@ThomasLandauer commented on GitHub (Oct 14, 2017): @kejwmen Yeah, I know that section, cause I wrote it ;-) https://github.com/doctrine/doctrine2/pull/6219 If that's the *only* reason why `addFeature()` is generated automatically, then I'd say it should only be created if `cascade:persist` is set.

admin commented

2026-01-22 15:16:04 +01:00

@mateuszsip commented on GitHub (Oct 14, 2017):

;) Nice work.

In my opinion it should, you always have a choice of cascade vs manual persist/remove.
Sometimes you need cascade (to manage entire aggregate) sometimes it could be dangerous (relations between aggregates).
And lack of cascade:persist doesn't imply you don't need addFeature.
The same thing about cascade:remove and removeFeature.

Maybe docs related to entity generator should link to that (working with associations) section?

@mateuszsip commented on GitHub (Oct 14, 2017): ;) Nice work. In my opinion it should, you always have a choice of cascade vs manual persist/remove. Sometimes you need cascade (to manage entire aggregate) sometimes it could be dangerous (relations between aggregates). And lack of `cascade:persist` doesn't imply you don't need `addFeature`. The same thing about `cascade:remove` and `removeFeature`. Maybe docs related to entity generator should link to that (working with associations) section?

admin commented

2026-01-22 15:16:06 +01:00

@ThomasLandauer commented on GitHub (Oct 14, 2017):

And lack of cascade:persist doesn't imply you don't need addFeature()

Why??
That's exactly the point I'm looking for! What's the purpose of addFeature(), if it isn't persisted in this case?

@ThomasLandauer commented on GitHub (Oct 14, 2017): > And lack of `cascade:persist` doesn't imply you don't need `addFeature()` Why?? That's exactly the point I'm looking for! What's the purpose of `addFeature()`, if it isn't persisted in this case?

admin commented

2026-01-22 15:16:06 +01:00

@lcobucci commented on GitHub (Oct 29, 2017):

@ThomasLandauer addFeature() can also be used with objects that were previously persisted. Like:

$product = new Product();
$product->addFeature($entityManager->find(Feature::class, 1));

The idea is just to associate entities, how to persist them should be something consciously designed by the developer. And we should use cascade operations with caution, since they add extra work to the UoW, which may impact on the performance of the software.

I hope this helps you to understand =)

@lcobucci commented on GitHub (Oct 29, 2017): @ThomasLandauer `addFeature()` can also be used with objects that were previously persisted. Like: ```php $product = new Product(); $product->addFeature($entityManager->find(Feature::class, 1)); ``` The idea is just to associate entities, how to persist them should be something consciously designed by the developer. And we should use cascade operations with caution, since they add extra work to the UoW, which may impact on the performance of the software. I hope this helps you to understand =)

admin commented

2026-01-22 15:16:06 +01:00

@ThomasLandauer commented on GitHub (Oct 29, 2017):

Well, OK, thanks!

So the bottom line is: It does make sense somehow, but only in these two cases, which both are rare:

cascade:persist
The added entity is already persisted

This should be explained in the docs somewhere! I justed looked around at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-associations.html but couldn't find an appropriate place. I didn't even find a decent explanation for those add*-functions - so probably that would be the first thing to do....

@ThomasLandauer commented on GitHub (Oct 29, 2017): Well, OK, thanks! So the bottom line is: It does make sense somehow, but *only* in these two cases, which both are rare: * `cascade:persist` * The `add`ed entity is already persisted This should be explained in the docs somewhere! I justed looked around at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-associations.html but couldn't find an appropriate place. I didn't even find a decent explanation for those `add*`-functions - so probably that would be the first thing to do....

admin commented

2026-01-22 15:16:07 +01:00

@mateuszsip commented on GitHub (Oct 29, 2017):

Thanks @lcobucci and sorry @ThomasLandauer - I forgot about you :(

@mateuszsip commented on GitHub (Oct 29, 2017): Thanks @lcobucci and sorry @ThomasLandauer - I forgot about you :(

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