DDC-1109: SINGLE_TABLE mapping fails to set the discriminator column value on persist if the mapping classes are specified with fully qualified namespace #1389

New Issue

admin · 2026-01-22T13:12:48+01:00

admin commented

2026-01-22 13:12:48 +01:00

Originally created by @doctrinebot on GitHub (Apr 10, 2011).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user simen:

If I specify a single inheritance structure with the mapping classes specified with fully qualified namespace in the annotation and then if I create a new mapped entity and try to save it, doctrine specifies the value for the discriminator column as NULL and thus the fush fails with mysql complaining the discriminator column to be NULL. If I specify the mapping classes without fully qualified namespace the persist works as expected

For example this fails:

<?php
namespace Entities;
/****
 * @Entity
 * @InheritanceType("SINGLE_TABLE")
 * @DiscriminatorColumn(name="itemType", type="integer")
 * @DiscriminatorMap({
 * "0"="\Entities\Data\Integer",
 * "5"="\Entities\Data\Text",
 * "6"="\Entities\Data\Form"
 * })
 */
class master {

But this works as expected:

<?php
namespace Entities;
/****
 * @Entity
 * @InheritanceType("SINGLE_TABLE")
 * @DiscriminatorColumn(name="itemType", type="integer")
 * @DiscriminatorMap({
 * "0"="Entities\Data\Integer",
 * "5"="Entities\Data\Text",
 * "6"="Entities\Data\Form"
 * })
 */
class master {

The obivous workaround for now is to not use fully qualified namespaced classes for the discriminator maps, but rather relative.

attached is the doctrine sanbox with the failing setup

Originally created by @doctrinebot on GitHub (Apr 10, 2011). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user simen: If I specify a single inheritance structure with the mapping classes specified with fully qualified namespace in the annotation and then if I create a new mapped entity and try to save it, doctrine specifies the value for the discriminator column as NULL and thus the fush fails with mysql complaining the discriminator column to be NULL. If I specify the mapping classes without fully qualified namespace the persist works as expected For example this fails: ``` <?php namespace Entities; /**** * @Entity * @InheritanceType("SINGLE_TABLE") * @DiscriminatorColumn(name="itemType", type="integer") * @DiscriminatorMap({ * "0"="\Entities\Data\Integer", * "5"="\Entities\Data\Text", * "6"="\Entities\Data\Form" * }) */ class master { ``` But this works as expected: ``` <?php namespace Entities; /**** * @Entity * @InheritanceType("SINGLE_TABLE") * @DiscriminatorColumn(name="itemType", type="integer") * @DiscriminatorMap({ * "0"="Entities\Data\Integer", * "5"="Entities\Data\Text", * "6"="Entities\Data\Form" * }) */ class master { ``` The obivous workaround for now is to not use fully qualified namespaced classes for the discriminator maps, but rather relative. attached is the doctrine sanbox with the failing setup

admin added the Bug label 2026-01-22 13:12:48 +01:00

admin closed this issue

2026-01-22 13:12:48 +01:00

admin commented

2026-01-22 13:12:49 +01:00

@doctrinebot commented on GitHub (Apr 30, 2011):

Comment created by @beberlei:

Namespaces are never referred with a leading prefix in strings. This is PHP convention. However we can easily ltrim the slash here in the mapping drivers for convenenince.

schedulding for 2.0.5

@doctrinebot commented on GitHub (Apr 30, 2011): Comment created by @beberlei: Namespaces are never referred with a leading prefix in strings. This is PHP convention. However we can easily ltrim the slash here in the mapping drivers for convenenince. schedulding for 2.0.5

admin commented

2026-01-22 13:12:50 +01:00

@doctrinebot commented on GitHub (Apr 30, 2011):

Comment created by @beberlei:

Fixed.

@doctrinebot commented on GitHub (Apr 30, 2011): Comment created by @beberlei: Fixed.

admin commented

2026-01-22 13:12:51 +01:00

@doctrinebot commented on GitHub (Apr 30, 2011):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Apr 30, 2011): Issue was closed with resolution "Fixed"

admin referenced this issue