[PR #11052] Fix @SequenceGeneratorDefinition inheritance, take 2 #12777

New Issue

admin · 2026-01-22T16:15:08+01:00

admin commented

2026-01-22 16:15:08 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/11052

State: closed
Merged: No

This is an alternative implementation to #11050. The difference is that with this PR here, once @SequenceGeneratorDefinition is used in an inheritance tree of entities and/or mapped superclasses, this definition (and in particular, the sequence name) will be inherited by all child entity/mapped superclasses.

Before #10455, the rules how @SequenceGeneratorDefinition is inherited from parent entity/mapped superclasses were as follows:

Entity and mapped superclasses inherit the ID generator type (as given by @GeneratedValue) from their parent classes
@SequenceGeneratorDefinition, however, is not generally inherited
... instead, a default sequence generator definition is created for every class when no explicit configuration is given. In this case, sequence names are based on the current class' table name.
Once a root entity has been identified, all subclasses inherit its sequence generator definition unchanged.

But, this has to be considered together with the quirky mapping driver behaviour that was deprecated in #10455: The mapping driver would not report public and protected fields from mapped superclasses, so these were virtually "pushed down" to the next entity classes.

That means @SequenceGeneratorDefinition on mapped superclasses would, in fact, be effective as-is for inheriting entity classes. This is what was covered by the tests in BasicInheritanceMappingTest that I marked with @group GH-10927.

My guess is that this PR will make it possible to opt-in to reportFieldsWhereDeclared (see #10455) and still get the same behaviour for mapped superclasses using @SequenceGeneratorDefinition as before. But maybe I don't see the full picture and all edge cases, so 👀 requested.

The GH10927Test test case validates the sequence names generated in a few cases. In fact, I wrote this test against the 2.15.x branch to make sure we get results that are consistent with the previous behaviour.

**Original Pull Request:** https://github.com/doctrine/orm/pull/11052 **State:** closed **Merged:** No --- This is an alternative implementation to #11050. The difference is that with this PR here, once `@SequenceGeneratorDefinition` is used in an inheritance tree of entities and/or mapped superclasses, this definition (and in particular, the sequence name) will be inherited by all child entity/mapped superclasses. Before #10455, the rules how `@SequenceGeneratorDefinition` is inherited from parent entity/mapped superclasses were as follows: * Entity and mapped superclasses inherit the ID generator type (as given by `@GeneratedValue`) from their parent classes * `@SequenceGeneratorDefinition`, however, is not generally inherited * ... instead, a default sequence generator definition is created for every class when no explicit configuration is given. In this case, sequence names are based on the current class' table name. * Once a root entity has been identified, all subclasses inherit its sequence generator definition unchanged. But, this has to be considered together with the quirky mapping driver behaviour that was deprecated in #10455: The mapping driver would not report public and protected fields from mapped superclasses, so these were virtually "pushed down" to the next entity classes. That means `@SequenceGeneratorDefinition` on mapped superclasses would, in fact, be effective as-is for inheriting entity classes. This is what was covered by the tests in `BasicInheritanceMappingTest` that I marked with `@group GH-10927`. My guess is that this PR will make it possible to opt-in to `reportFieldsWhereDeclared` (see #10455) and still get the same behaviour for mapped superclasses using `@SequenceGeneratorDefinition` as before. But maybe I don't see the full picture and all edge cases, so 👀 requested. The `GH10927Test` test case validates the sequence names generated in a few cases. In fact, I wrote this test against the `2.15.x` branch to make sure we get results that are consistent with the previous behaviour.

admin added the pull-request label 2026-01-22 16:15:08 +01:00

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#12777

[PR #11052] Fix @SequenceGeneratorDefinition inheritance, take 2 #12777

[PR #11052] Fix `@SequenceGeneratorDefinition` inheritance, take 2 #12777