IDENTITY identifier strategy for PostgreSQL breaks when inherited from MappedSuperclass

[DemoniacDeath]

BC Break Report

Q	A
BC Break	yes
Version	2.16.0

Summary

Persisting an @Entity which has it's @Id defined in it's parent (@MappedSuperclass) with IDENTITY generator strategy on PostgreSQL platform.
It seems that the breaking change occured in this PR #10455, specifically changes in ClassMetadataFactory that removed the condtion of $rootEntityFound for calling inheritIdGeneratorMapping()

Previous behavior

In version 2.15.5 the IdentityGenerator used to retrieve inserted id came from the Entity itself with $sequenceName matching the schema. So the value was retrieved from the correct sequence.

Current behavior

Now the IdentityGenerator used to retrieve inserted id comes from the parent @MappedSuperclass and $sequenceName is wrong (name of parent class + sequence suffix) and non-existent in schema, so a PostgreSQL error about relation not existing is thrown.

How to reproduce

E.g. (irrelevant code and domain-specific terminology is ommited):

/**
 * @ORM\MappedSuperclass
 */
abstract class AbstractTaskOperatorHistoryRecord
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    private ?int $id = null;
}

/**
 * @ORM\Entity()
 * @ORM\Table(name="foo_bar_task_operator_history")
 */
class FooBarTaskOperatorHistoryRecord extends AbstractTaskOperatorHistoryRecord
{
}

$this->_em->persist(new FooBarTaskOperatorHistoryRecord());
$this->_em->flush();

The PostgreSQL sequence used by id column in foo_bar_task_operator_history table is foo_bar_task_operator_history_id_seq.
The sequence used to retrieve inserted id was foo_bar_task_operator_history_id_seq before the breaking change. Now it is trying to get the value from abstracttaskoperatorhistoryrecord_id_seq which obviously does not and should not exist. The error thrown is

PDOException

SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "abstracttaskoperatorhistoryrecord_id_seq" does not exist

[pkly]

I've noticed a similar issue in one of our projects, running on MariaDB, similarly with a parent entity (DiscriminatorMap + Joined inheritance) but in our case I see:

An exception occurred while executing a query: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

2.15.5 works as expected, 2.16.0 crashes on the same code.
We have a parent entity with a generated id value, the child entity also contains an automatically generated uuid value (via custom generator).

[julienbrunet21]

Hello I found a workaround which consists of changing the parent's id to protected instead of private

[DemoniacDeath]

Hello I found a workaround which consists of changing the parent's id to protected instead of private

changing id property from private to protected did not change the result of failing test case #10928 for me

[mpdude]

@DemoniacDeath did you opt into the new „report fields where declared“ setting?

[DemoniacDeath]

@mpdude

OrmFunctionalTestCase.php:803

        $config->setMetadataDriverImpl(
            $mappingDriver ?? ORMSetup::createDefaultAnnotationDriver([
                realpath(__DIR__ . '/Models/Cache'),
                realpath(__DIR__ . '/Models/GeoNames'),
            ], null, true)
        );

it is set to true in the failing test case (by default). changing it to false did not change the outcome.

AFAIUI the issue is specifically with the code in \Doctrine\ORM\Mapping\ClassMetadataFactory::doLoadMetadata

[melroy89]

Mbin is also effected by this regression issue of Doctrine: MbinOrg/mbin#147

[mpdude]

I see two ways how this could be fixed.

The first one is in #11050. It reverts the way inheritance works for @SequenceGeneratorDefinition and mapped superclasses. But, with this change one cannot define @SequenceGeneratorDefinition on mapped superclasses and expect it to be inherited by child entity classes - at least not when using the new reportFieldsWhereDeclared mapping driver mode.

The second approach is in #11052. It will recognize when an explicit @SequenceGeneratorDefinition is used and pass that one on unchanged to child classes (= all use the same sequence name). Otherwise, the default one will be generated for every single class, so the sequence name is based on the table name.