All sequences merged into one since the merge of #10455

[NoiseByNorthwest]

Bug Report

All sequences merged into one since the merge of #10455

Q	A
BC Break	yes if the generated SQL (DDL) is an API boundary
Version	2.16.2 (last known good 2.15.5)

Summary

Since the upgrade of doctrine/orm from 2.15.5 to 2.16.2 all sequences, as resolved by ClassMetadataFactory, are replaced by a single one.

It seems to be a side effect of #10455.
Is it a bug ?
Or is there a way (config ?) or recommended workaround to have the original behavior ?

Current behavior

Since 2.16 (2.16.2) all concrete classes now share the same sequence, which has BTW a name based on the super class's one.

How to reproduce

We have a sequence defined in a mapped super class

/**
 * @ORM\HasLifecycleCallbacks
 * @ORM\MappedSuperclass
 */
abstract class BaseModel
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column( type = "integer", name = "id" )
     *
     * @readonly
     */
    private int $id;
}

/**
 * @ORM\Entity
 * @ORM\Table
 */
class Foo extends BaseModel
{
}

/**
 * @ORM\Entity
 * @ORM\Table
 */
class Bar extends BaseModel
{
}

Expected behavior

Before 2.16 (2.15.5) all concrete classes had their own sequence.
That means, with the provided reproducer, that Foo and Bar must have their own sequence.

[derrabus]

Please tell us which database you are using and provide a full reproducer. I only see one abstract class.

[NoiseByNorthwest]

Please tell us which database you are using and provide a full reproducer. I only see one abstract class.

I've completed the reproducer.
We use PostgreSQL 15.3 as database.

[NoiseByNorthwest]

Very close to the one described here #10927, same root cause but slightly different interpretation of the unexpected behavior.
@DemoniacDeath have you tried to generate a migration ? Doesn't it generate the required DDL in order to create the new sequence and remove the per-table ones ?

[DemoniacDeath]

Very close to the one described here #10927, same root cause but slightly different interpretation of the unexpected behavior. @DemoniacDeath have you tried to generate a migration ? Doesn't it generate the required DDL in order to create the new sequence and remove the per-table ones ?

I did not, but here is a failing test case #10928 and it does it's own migrations, so SchemaTool is not affected, only ClassMetadataFactory . That's actually surprising because SchemaTool seems to use the results of ClassMetadataFactory. Maybe the order of entities in setUpEntitySchema matters? I'm not currently at the workstation where I can test things

[NoiseByNorthwest]

Very close to the one described here #10927, same root cause but slightly different interpretation of the unexpected behavior. @DemoniacDeath have you tried to generate a migration ? Doesn't it generate the required DDL in order to create the new sequence and remove the per-table ones ?

I did not, but here is a failing test case #10928 and it does it's own migrations, so SchemaTool is not affected, only ClassMetadataFactory . That's actually surprising because SchemaTool seems to use the results of ClassMetadataFactory. Maybe the order of entities in setUpEntitySchema matters? I'm not currently at the workstation where I can test things

Yes this is strange, from my observations your test should pass in 2.16 (with the gh10927parent_id_seq properly created).

[mpdude]

I believe this is the same as #10927

[melroy89]

I'm also effected by this regression problem after Composer recipe update. Doctrine option will set report_fields_where_declared: true, which opt-in in the new mapping driver mode causing regression as described in this issue ticket.

Please, do not turn on this feature by default when running the doctrine-bundle recipe update OR ... fix the PostgreSQL sequence number generator with class inheritance regression problem asap, caused by #10455.

[mpdude]

@NoiseByNorthwest

Did #11050 fix this? If so, please close.

[NoiseByNorthwest]

I'll try to check that this week.

[NoiseByNorthwest]

I confirm this is the fix 👍