DDC-3386: Multiple Level Discriminator Mapping #4183

New Issue

2026-01-22T14:36:52+01:00

admin commented

2026-01-22 14:36:52 +01:00

Originally created by @doctrinebot on GitHub (Nov 11, 2014).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user DrugCrazed:

We currently have a situation where we're required to have up to 4 levels of discriminator mappings, and we're finding that Doctrine will insert into our root entity table, and the leaf entity table correctly. However, the tables in between are not being set at all.

The hierarchy is below:

Deal -> EcommerceDeal
Deal -> EcommerceDeal -> ItemSpecific
Deal -> EcommerceDeal -> ItemSpecific -> ItemSpecificScheduled
Deal -> EcommerceDeal -> DealSet -> SetCombo
Deal -> EcommerceDeal -> DealSet -> SetMoreForLess

When inserting an ItemSpecific entity, I found that the Deal and ItemSpecific tables were filled but the EcommerceDeal was not.

There's not much documentation about trees that are slightly more complicated than the Employee, Person, Admin example in the docs so there's a chance I've misunderstood how to build the tables correctly.

Currently we only have one discriminator column on the Deal table. Should we instead be setting up several columns that are nullable and setting new discriminator columns further down the tree?

EDIT: All classes are Class Table Inheritance, in case that is unclear

Originally created by @doctrinebot on GitHub (Nov 11, 2014). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user DrugCrazed: We currently have a situation where we're required to have up to 4 levels of discriminator mappings, and we're finding that Doctrine will insert into our root entity table, and the leaf entity table correctly. However, the tables in between are not being set at all. The hierarchy is below: ``` Deal -> EcommerceDeal Deal -> EcommerceDeal -> ItemSpecific Deal -> EcommerceDeal -> ItemSpecific -> ItemSpecificScheduled Deal -> EcommerceDeal -> DealSet -> SetCombo Deal -> EcommerceDeal -> DealSet -> SetMoreForLess ``` When inserting an `ItemSpecific` entity, I found that the `Deal` and `ItemSpecific` tables were filled but the EcommerceDeal was not. There's not much documentation about trees that are slightly more complicated than the `Employee`, `Person`, `Admin` example in the docs so there's a chance I've misunderstood how to build the tables correctly. Currently we only have one discriminator column on the `Deal` table. Should we instead be setting up several columns that are nullable and setting new discriminator columns further down the tree? EDIT: All classes are Class Table Inheritance, in case that is unclear

admin added the Bug label 2026-01-22 14:36:52 +01:00

admin commented

2026-01-22 14:36:53 +01:00

@doctrinebot commented on GitHub (Nov 11, 2014):

Comment created by DrugCrazed:

The thing that always confuses me while I'm working on this is the fact that I can select from the Database fine. I've got dummy data in each table and Doctrine is clever enough to select all the correct fields from the correct tables so I'm unsure whether I've made a mistake or if Doctrine has a bug.

@doctrinebot commented on GitHub (Nov 11, 2014): Comment created by DrugCrazed: The thing that always confuses me while I'm working on this is the fact that I can select from the Database fine. I've got dummy data in each table and Doctrine is clever enough to select all the correct fields from the correct tables so I'm unsure whether I've made a mistake or if Doctrine has a bug.

admin commented

2026-01-22 14:36:53 +01:00

@doctrinebot commented on GitHub (Nov 11, 2014):

Comment created by @ocramius:

This looks like normal ORM behavior to me, not really requiring any change. What's the reason for inserts on the other tables?

@doctrinebot commented on GitHub (Nov 11, 2014): Comment created by @ocramius: This looks like normal ORM behavior to me, not really requiring any change. What's the reason for inserts on the other tables?

admin commented

2026-01-22 14:36:53 +01:00

@doctrinebot commented on GitHub (Nov 12, 2014):

Comment created by DrugCrazed:

We have data that's the same across all Ecommerce Deal types (things like the start time, end time etc). I'd expect to be able to set all the values on (say) an ItemSpecific deal and Doctrine to insert the generic data in the EcommerceDeal table.

@doctrinebot commented on GitHub (Nov 12, 2014): Comment created by DrugCrazed: We have data that's the same across all Ecommerce Deal types (things like the start time, end time etc). I'd expect to be able to set all the values on (say) an `ItemSpecific` deal and Doctrine to insert the generic data in the `EcommerceDeal` table.

admin commented

2026-01-22 14:36:54 +01:00

@doctrinebot commented on GitHub (Nov 12, 2014):

Comment created by DrugCrazed:

It turns out that Doctrine does support this out of the box. A predecessor had overriden the JoinedSubclassPersister with the sole purpose being to comment out the section relating to discriminator columns.

@doctrinebot commented on GitHub (Nov 12, 2014): Comment created by DrugCrazed: It turns out that Doctrine **does** support this out of the box. A predecessor had overriden the `JoinedSubclassPersister` with the sole purpose being to comment out the section relating to discriminator columns.

admin commented

2026-01-22 14:36:54 +01:00

@doctrinebot commented on GitHub (Nov 12, 2014):

Comment created by DrugCrazed:

Problem is with an overridden method not in the Doctrine core.

@doctrinebot commented on GitHub (Nov 12, 2014): Comment created by DrugCrazed: Problem is with an overridden method not in the Doctrine core.

admin commented

2026-01-22 14:36:55 +01:00

@doctrinebot commented on GitHub (Nov 13, 2014):

Comment created by @ocramius:

[~DrugCrazed] do you mean that your version (local file) of the JoinedSubclassPersister was monkey-patched?

@doctrinebot commented on GitHub (Nov 13, 2014): Comment created by @ocramius: [~DrugCrazed] do you mean that your version (local file) of the `JoinedSubclassPersister` was monkey-patched?

admin commented

2026-01-22 14:36:55 +01:00

@doctrinebot commented on GitHub (Nov 13, 2014):

Comment created by DrugCrazed:

Undoing monkey patch does not fully fix issue

@doctrinebot commented on GitHub (Nov 13, 2014): Comment created by DrugCrazed: Undoing monkey patch does not fully fix issue

admin commented

2026-01-22 14:36:55 +01:00

@doctrinebot commented on GitHub (Nov 13, 2014):

Comment created by DrugCrazed:

Marco: We'd overridden a whole bunch of classes to do various things, but I've got no idea what those were (these happened at least 6 months before I joined).

The JoinedSubclassPersister was overridden and just commented out two lines

$tableAlias = ($this->class->rootEntityName == $this->class->name) ? $baseTableAlias : $this->getSQLTableAlias($this->class->rootEntityName);
$columnList[] = $tableAlias . '.' . $discrColumn;

From speaking to people, it seems that the point of using that was to allow the discriminator columns to be on the incorrect tables.

However, even with undoing this, I've just tried to create a ComboDeal and it inserted into the root table and the leaf table but none of the other tables. However it looks like ItemSpecific entities are fine. I'll just retry creation of each entity type and get back to you.

@doctrinebot commented on GitHub (Nov 13, 2014): Comment created by DrugCrazed: Marco: We'd overridden a whole bunch of classes to do various things, but I've got no idea what those were (these happened at least 6 months before I joined). The `JoinedSubclassPersister` was overridden and just commented out two lines ``` $tableAlias = ($this->class->rootEntityName == $this->class->name) ? $baseTableAlias : $this->getSQLTableAlias($this->class->rootEntityName); $columnList[] = $tableAlias . '.' . $discrColumn; ``` From speaking to people, it seems that the point of using that was to allow the discriminator columns to be on the incorrect tables. However, even with undoing this, I've just tried to create a `ComboDeal` and it inserted into the root table and the leaf table but none of the other tables. However it looks like `ItemSpecific` entities are fine. I'll just retry creation of each entity type and get back to you.

admin commented

2026-01-22 14:36:55 +01:00

@doctrinebot commented on GitHub (Nov 13, 2014):

Comment created by DrugCrazed:

Just finished doing that. I can create EcommerceDeal entities, and ItemSpecific entities and they'll insert into the correct tables (so the EcommerceDeal entity saves into the EcommerceDeal and Deal tables, and the ItemSpecific entity saves into the ItemSpecific, EcommerceDeal and Deal tables).

The rest only insert into the Deal table and the table relating to that class.

@doctrinebot commented on GitHub (Nov 13, 2014): Comment created by DrugCrazed: Just finished doing that. I can create `EcommerceDeal` entities, and `ItemSpecific` entities and they'll insert into the correct tables (so the `EcommerceDeal` entity saves into the `EcommerceDeal` and `Deal` tables, and the `ItemSpecific` entity saves into the `ItemSpecific`, `EcommerceDeal` and `Deal` tables). The rest only insert into the `Deal` table and the table relating to that class.

admin commented

2026-01-22 14:36:55 +01:00

@doctrinebot commented on GitHub (Nov 18, 2014):

Comment created by DrugCrazed:

Is there an update on how we can resolve this?

@doctrinebot commented on GitHub (Nov 18, 2014): Comment created by DrugCrazed: Is there an update on how we can resolve this?

admin commented

2026-01-22 14:36:56 +01:00

@doctrinebot commented on GitHub (Nov 18, 2014):

Comment created by DrugCrazed:

We've spent a day looking through and trying to work out what seems to be happening and seem to have a resolution.

It appears that the method of getting the parents was only getting those which weren't transient (and thus were entities), which in our case wasn't working since then Doctrine complains about duplicate column definitions. After overriding the getParentClass to allow us to be explicit we got it to work.

@doctrinebot commented on GitHub (Nov 18, 2014): Comment created by DrugCrazed: We've spent a day looking through and trying to work out what seems to be happening and seem to have a resolution. It appears that the method of getting the parents was only getting those which weren't transient (and thus were entities), which in our case wasn't working since then Doctrine complains about duplicate column definitions. After overriding the getParentClass to allow us to be explicit we got it to work.

admin referenced this issue

2026-01-22 16:07:20 +01:00

[PR #7207] connect to master for schema updates #10374

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#4183