mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Why does my entity need an arbitrary ::getId() method in this scenario? #7129
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 @danielrhodeswarp on GitHub (Apr 11, 2023).
Bug Report
Summary
I have a "parent" entity (Grouping) which may have zero, one or more "child" entities (GroupingAssociation).
Grouping has a few standard text and date fields.
GroupingAssociation is a polymorphic tracking table and it stores Individuals (another Doctrine entity) and / or Services (another Doctrine entity) that may belong to a Grouping.
One novel thing with the GroupingAssociation entity is that it does not have a single primary identifier column of its own - its primary key is a composite of every field that it has. (And I suspect that this might be the cause of the issue.)
Current behavior
I can only persist() and flush() my Grouping and GroupingAssociation entities if I add an arbitrary
getID()method to the GroupingAssociation entity.If I do not have this arbitrary
getID()method - I get this error:How to reproduce
I get the error every time with the following controller method and configuration of entities:
Expected behavior
I would not expect to have to insert an arbitrary
getId()method into an entity that doesn't have an "id" column, or that doesn't have a single primary key column.@mpdude commented on GitHub (Apr 12, 2023):
Can you use a debugger to find out when/why/where the code reaches/calls that getId()` method?
Also, I notice you're using the same property as the
@Idcolumn and declare it to be an association. I guess this is valid, but at the same time it's a pattern I have seen rarely until today.@danielrhodeswarp commented on GitHub (Apr 14, 2023):
Thanks @mpdude , yes I think the quirkiness here stems from having such an unusual primary key on my entity.
Debugging - and even just stack tracing - is a great idea that I will look into.
Who knows, this could be an actual bug in Doctrine?
@danielrhodeswarp commented on GitHub (Apr 14, 2023):
Ah, OK, well I think we can close this issue as far as it being an issue with Doctrine.
The thing that is trying to call ->getID() is the data-dog/audit-bundle package that I am using.
So either a bug or a mis-configuration with data-dog and nothing sinister with Doctrine :-)