DDC-3512: Redesign ClassMetadata API as ValueObject based (for type-safety and self-documentation) #4326

New Issue

admin · 2026-01-22T14:39:29+01:00

admin commented

2026-01-22 14:39:29 +01:00

Originally created by @doctrinebot on GitHub (Jan 17, 2015).

Originally assigned to: @Ocramius on GitHub.

Jira issue originally created by user @ocramius:

The current ClassMetadata API is based on a lot of array juggling (for performance reasons).

While that was understandable with PHP 5.3, all the array access operations are currently:

slowing things down
making the code very hard to read/understand

I suggest re-coding the ClassMetadata internals (public properties and such) so that well-described properties are defined.

Additionally, as a bonus, we'd get a performance boost by just moving all the class-alias and type resolution logic from the runtime into the ClassMetadataFactory (or similar) API, saving tons of performance at every run.

In pseudo-logic, what I'd like to achieve with DDC-3512 is:

base metadata is loaded from the mapping driver
onLoadMetadata event is fired for each loaded metadata instance
metadata is completed by the ClassMetadataFactory logic
onCompleteMetadata event is fired for each loaded metadata instance

This would make metadata manipulation from events a bit messier (user needs to know which value to change during which event), but would allow using better constrained metadata structures in future, and that would disallow mistakes during event listeners execution as well (internal validation).

Originally created by @doctrinebot on GitHub (Jan 17, 2015). Originally assigned to: @Ocramius on GitHub. Jira issue originally created by user @ocramius: The current ClassMetadata API is based on a lot of array juggling (for performance reasons). While that was understandable with PHP 5.3, all the array access operations are currently: - slowing things down - making the code very hard to read/understand I suggest re-coding the ClassMetadata internals (public properties and such) so that well-described properties are defined. Additionally, as a bonus, we'd get a performance boost by just moving all the class-alias and type resolution logic from the runtime into the ClassMetadataFactory (or similar) API, saving tons of performance at every run. In pseudo-logic, what I'd like to achieve with [DDC-3512](http://www.doctrine-project.org/jira/browse/DDC-3512) is: - base metadata is loaded from the mapping driver - `onLoadMetadata` event is fired for each loaded metadata instance - metadata is completed by the `ClassMetadataFactory` logic - `onCompleteMetadata` event is fired for each loaded metadata instance This would make metadata manipulation from events a bit messier (user needs to know which value to change during which event), but would allow using better constrained metadata structures in future, and that would disallow mistakes during event listeners execution as well (internal validation).

admin added the Improvement label 2026-01-22 14:39:29 +01:00

admin closed this issue

2026-01-22 14:39:29 +01:00

admin commented

2026-01-22 14:39:29 +01:00

@doctrinebot commented on GitHub (Jan 17, 2015):

relates to DDC-3503: [GH-1257] Resolve target entity also in discriminator map (allows interfaces and custom names in discriminator map)

@doctrinebot commented on GitHub (Jan 17, 2015): - relates to [DDC-3503: [GH-1257] Resolve target entity also in discriminator map (allows interfaces and custom names in discriminator map)](https://github.com/doctrine/doctrine2/issues/1257)

admin commented

2026-01-22 14:39:29 +01:00

@guilhermeblanco commented on GitHub (Jan 4, 2017):

This is already under work as part of 3.0 efforts. Closing for now.

@guilhermeblanco commented on GitHub (Jan 4, 2017): This is already under work as part of 3.0 efforts. Closing for now.

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