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

New Issue

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

admin commented

2026-01-22 14:39:26 +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:26 +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#4324