[DDC-1776] Abstract class marked as @Entity in a single table inheritance is wrongly hydrated Created: 14/Apr/12 Updated: 01/May/13 Resolved: 01/May/13 |
|
| Status: | Resolved |
| Project: | Doctrine 2 - ORM |
| Component/s: | ORM |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Benjamin Morel | Assignee: | Marco Pivetta |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Irrelevant |
||
| Description |
|
I have the following entity hierarchy: /** * @Entity * @InheritanceType("SINGLE_TABLE") * @DiscriminatorColumn(name="type", type="string") * @DiscriminatorMap({ "prospectEdited" = "Application\Domain\Model\Event\ProspectEditedEvent" }) */ abstract class Event { // ... } /** * @Entity */ abstract class ProspectEvent extends Event { /** * @ManyToOne(targetEntity="Application\Domain\Model\Prospect") */ protected $prospect; } /** * @Entity */ class ProspectEditedEvent extends ProspectEvent { // ... } Although ProspectEvent is an abstract class, I need to mark it as @Entity, so that I can query for any type of ProspectEvent: SELECT e FROM ProspectEvent e WHERE e.prospect = ? So far, so good. SELECT e FROM Event e The query works fine, but the returned ProspectEvent entities have a NULL $prospect property. The workaround to make it work, is to add a "fake" entry to the discriminator map for the abstract class:
@DiscriminatorMap({
"prospectEvent" = "Application\Domain\Model\Event\ProspectEvent"
"prospectEdited" = "Application\Domain\Model\Event\ProspectEditedEvent"
})
Even though there is no such "prospectEvent" discriminator entry possible, as the class is abstract. |
| Comments |
| Comment by Benjamin Morel [ 29/Nov/12 ] |
|
Any feedback? |
| Comment by Marco Pivetta [ 23/Jan/13 ] |
|
Benjamin Morel I'd say this has to be fixed in validation. What if we enforce the fake discriminator map? The "workaround" you suggested is actually what you should write with correct mappings. |
| Comment by Marco Pivetta [ 09/Feb/13 ] |
|
Yes, this has to be reported in validation somehow. The "workaround" is not actually a workaround, but what is expected to be written by the developer. |
| Comment by Benjamin Morel [ 10/Feb/13 ] |
|
Ok, I found this weird because it's impossible to store a ProspectEvent in the database (as it's abstract), so adding a discriminator entry for it looks weird to me.
But leaving the error unreported, and instantiating incomplete objects, is a real danger! |
| Comment by Benjamin Eberlei [ 01/May/13 ] |
|
We fixed errors of this kind a while ago |