mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-2089: Modify OneToMany to allow unidirectional associations without the need of a JoinTable #2633
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Oct 19, 2012).
Originally assigned to: @beberlei on GitHub.
Jira issue originally created by user noise085:
As I sayd in the title, it would be nice if the ORM layer could permit to map a 1:n association in the db as an unidirectional OneToMany in the classes, without using a JoinTable in the database.
This would permit us to get rid of the unnecessary database JoinTable, which creates disorder and decreases performance for no valuable reason.
Is it possible?
@doctrinebot commented on GitHub (Dec 16, 2012):
Comment created by noise085:
A little up... for inspiration from JPA :)
https://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Unidirectional_OneToMany,_No_Inverse_ManyToOne,No_Join_Table(JPA_2.x_ONLY)
@doctrinebot commented on GitHub (Oct 7, 2014):
Comment created by danielpitts:
This is also a big issue for Symfony2 forms. It's very difficult to make a form type for a collection of "things", where the "things" are fully owned by the parent object.
@doctrinebot commented on GitHub (Jun 5, 2015):
Comment created by Fruchuxs:
There are any plans to implement this feature?
The unidirection OneToMany with JoinTable is a little bit tricky, because in some cases you can't remove entities from parent. Also its not a real "Object-relation-mapping" because you need to add a (unnecessary) inverse field. This brakes the object domain model.
E.g.: If you have an entity Account which holds a collectionof Members (unidirectional) and now you want to remove a Member from the collection you get an "Cannot delete or update a parent row: a foreign key constraint fails " error ...
@beberlei commented on GitHub (May 12, 2022):
This would be nice to have, but implementation wise is quite complicated.