DDC-893: Feature Request: Automatic update of bidirectional associations. #1108

Closed
opened 2026-01-22 13:02:28 +01:00 by admin · 4 comments
Owner

Originally created by @doctrinebot on GitHub (Nov 25, 2010).

Jira issue originally created by user dalvarez:

This is a feature request.

It would be nice to have bidirectional associations updated automatically, i. e. have updates to one end reflected on the other.

This is a basic and natural feature, and I don't see the point of not supporting it, as Doctrine 2 knows about the bidirectionality anyway since it is declared.

It is just a pain to have to set association values on two objects always, once you want to work in-memory with an object graph.

Why make the user bother about it? If there are special circumstances where we don't want objects to be changed implicitly (for whatever reason) it could still be made optional.

Originally created by @doctrinebot on GitHub (Nov 25, 2010). Jira issue originally created by user dalvarez: This is a feature request. It would be nice to have bidirectional associations updated automatically, i. e. have updates to one end reflected on the other. This is a basic and natural feature, and I don't see the point of not supporting it, as Doctrine 2 knows about the bidirectionality anyway since it is declared. It is just a pain to have to set association values on two objects always, once you want to work in-memory with an object graph. Why make the user bother about it? If there are special circumstances where we don't want objects to be changed implicitly (for whatever reason) it could still be made optional.
admin added the New Feature label 2026-01-22 13:02:28 +01:00
admin closed this issue 2026-01-22 13:02:29 +01:00
Author
Owner

@doctrinebot commented on GitHub (Nov 25, 2010):

Comment created by romanb:

This is a design decision and would be against some core ideas of the project. If bidirectional associations are completed automatically by the persistence layer on new objects, your domain model, which was supposed to be persistence-agnostic, is broken in a subtle way without the persistence layer in place. Doctrine2 is meant to persist your domain model, not to fix it. If your domain model does not properly deal with associations, it is broken. Letting the persistence layer fix it is a bad choice as the model remains broken and this will show in unit tests of these models without a persistence service involved.

@doctrinebot commented on GitHub (Nov 25, 2010): Comment created by romanb: This is a design decision and would be against some core ideas of the project. If bidirectional associations are completed automatically by the **persistence layer** on new objects, your domain model, which was supposed to be persistence-agnostic, is broken in a subtle way without the persistence layer in place. Doctrine2 is meant to persist your domain model, not to fix it. If your domain model does not properly deal with associations, it is broken. Letting the persistence layer fix it is a bad choice as the model remains broken and this will show in unit tests of these models without a persistence service involved.
Author
Owner

@doctrinebot commented on GitHub (Nov 25, 2010):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Nov 25, 2010): Issue was closed with resolution "Won't Fix"
Author
Owner

@doctrinebot commented on GitHub (Nov 27, 2010):

Comment created by dalvarez:

I get your Point. Of course, the domain model in my application currently does take care of updating bidirectional relationships. But then again, I would prefer if it would not need to.

I could implement the updating of bidirectional relationships in the entity base class of my domain model then, so updates would be taken care of generically by analyzing and acting upon the declared Doctrine 2 metadata at a central point of responsibility (a generic **set method), and not scattered throughout the application every time I set the value of an association. This would keep the business logic's ability to stand for itself intact. The downside is that for such a generic solution I would have to deal with Doctrine 2 annotations in userland code, or duplicate them. I agree that integrating the feature into Doctrine would compromise the business code's ability to stand by itself. Then again, generation of identifier values by Doctrine 2 also does compromise it, in much the same way.

@doctrinebot commented on GitHub (Nov 27, 2010): Comment created by dalvarez: I get your Point. Of course, the domain model in my application currently does take care of updating bidirectional relationships. But then again, I would prefer if it would not need to. I could implement the updating of bidirectional relationships in the entity base class of my domain model then, so updates would be taken care of generically by analyzing and acting upon the declared Doctrine 2 metadata at a central point of responsibility (a generic **set method), and not scattered throughout the application every time I set the value of an association. This would keep the business logic's ability to stand for itself intact. The downside is that for such a generic solution I would have to deal with Doctrine 2 annotations in userland code, or duplicate them. I agree that integrating the feature into Doctrine would compromise the business code's ability to stand by itself. Then again, generation of identifier values by Doctrine 2 also does compromise it, in much the same way.
Author
Owner

@doctrinebot commented on GitHub (Nov 27, 2010):

Comment created by @beberlei:

Handling bidirectional associations is three lines of code in each entity, which can even be generated by an IDE. I don't see the problem here.

ID Management is something different imho. All persistence solutions work with ID. An Entity has identity, hence an ID.

@doctrinebot commented on GitHub (Nov 27, 2010): Comment created by @beberlei: Handling bidirectional associations is three lines of code in each entity, which can even be generated by an IDE. I don't see the problem here. ID Management is something different imho. All persistence solutions work with ID. An Entity has identity, hence an ID.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#1108