DDC-3618: Refactor PersistentCollection #4446

New Issue

admin · 2026-01-22T14:41:46+01:00

admin commented

2026-01-22 14:41:46 +01:00

Originally created by @doctrinebot on GitHub (Mar 16, 2015).

Originally assigned to: @guilhermeblanco on GitHub.

Jira issue originally created by user vbence:

PersistentCollection - a final class - contains all the metadata, used to speed up updates (through $snapshot). This information should be removed from the collection object and stored elsewhere, loosely coupled.

Doctrine2 uses the data mapper pattern (instead of Doctrine1's active record approach). This tells me that the designers see the importance of freedom which comes with loose coupling. Entities don't have to extend fixed base classes, why do collections?

Use case: I would like to use a wrapper around Collection (my current environment requires collections to have a certain functionality). This is possible in theory, but as I do the first step I'm losing all the advantages coming with PersistentColelction. Since it is a final class and logically an interface by itself (see the sniffing in ObjectHydrator#initRelatedCollection) it is impossible to create a wrapper which exposes the same functionality.

A short-term solution would be to extract an interface from PersistentColelction. A long-term one would be to manage the persisted state (currently PersistentCollection#snapshot) elsewhere (accessed through the EntityManager maybe).

Originally created by @doctrinebot on GitHub (Mar 16, 2015). Originally assigned to: @guilhermeblanco on GitHub. Jira issue originally created by user vbence: PersistentCollection - a final class - contains all the metadata, used to speed up updates (through $snapshot). This information should be removed from the collection object and stored elsewhere, loosely coupled. Doctrine2 uses the data mapper pattern (instead of Doctrine1's active record approach). This tells me that the designers see the importance of freedom which comes with loose coupling. Entities don't have to extend fixed base classes, why do collections? Use case: I would like to use a wrapper around Collection (my current environment requires collections to have a certain functionality). This is possible in theory, but as I do the first step I'm losing all the advantages coming with PersistentColelction. Since it is a final class and logically an interface by itself (see the sniffing in ObjectHydrator#initRelatedCollection) it is impossible to create a wrapper which exposes the same functionality. A short-term solution would be to extract an interface from PersistentColelction. A long-term one would be to manage the persisted state (currently PersistentCollection#snapshot) elsewhere (accessed through the EntityManager maybe).

admin added the Improvement label 2026-01-22 14:41:46 +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#4446