Affects Version/s: None
Fix Version/s: 2.4
Security Level: All
This issue is created automatically through a Github pull request on behalf of sroddy:
... a STI use the same field to map relations with entities of different classes
It seems that there are no particular side-effects in mapping different relationship using the same table column name in different subclasses of a STI hierarchy.
Eg. Tag superclass of BookTag (id, object_id, comment) and MovieTag (id, object_id, comment), so having two attributes $book and $movie mapped to the same object_id field with @JoinColumn annotation
I wasn't sure about this so I tested to see if there were errors. And I was surprised that everything runs without any particular problem.
Moreover this is a really interesting (wanted? unwanted?) feature, very useful if you have huge tables that need to be joined with other table using the discriminator and object_id columns, or if you have some kind of logging class and you need to keep the table efficient and small. The only problem is that the schema generator always inserts a foreign column constraint (probably the last specified) when generating these kind of Entities.
This PR ensures that the foreign key is not added if there are at least two different classes mapped on the same field of a db table.