Bug #88613
open
Replace ObjectStorage & LazyObjectStorage with symfony/collection
Added by Oliver Hader almost 5 years ago.
Updated over 1 year ago.
Description
For regular ObjectStorage deserialization most probably would work - however there are inconsitencies concerning object integrity due to ObjectStorage using spl_object_hash() internally. In a result it would not be possible to detach an object retrieved from repository from some deserialized ObjectStorage - basically uid should be used as identifier here which would turn ObjectStorage into EntityStorage. So, we could live with serialization of ObjectStorage.
For LazyObjectStorage things are getting more difficult since serialization of it would mean to serialize backreferences to parent object as well as DataMapper state, ObjectManager state and in the end class Reflection state - that turns out to be a massive collection of serialized data.
Thus, we experience most pain with LazyObjectStorage and its current implementation.
- Status changed from New to Under Review
- Description updated (diff)
@Alexander Schnitzler (https://review.typo3.org/c/Packages/TYPO3.CMS/+/61118/3#message-e5ec8c4a56d55a65395753969b7d240c8effc6cb)
I am planning to replace our ObjectStorage with doctrine/collection anyway. That also means, that our Lazy-Objects won't be used any more. The Collection also doesn't have any services injected, its state is handled from the outside. So, if we don't have issues with people trying to serialize their object storages at the moment, I'd say, let's abandon this patch and work on a better implementation.
- Subject changed from Properly deny serialization of Extbase object storage to Substitute ObjectStorage & LazyObjectStorage with symfony/collection
- Status changed from Under Review to Accepted
- Subject changed from Substitute ObjectStorage & LazyObjectStorage with symfony/collection to Replace ObjectStorage & LazyObjectStorage with symfony/collection
- Priority changed from Should have to Won't have this time
This will not make it into 10. The change is quite invasive as it forces users to touch their code. The mere inner representation of collections is not so much the issue but at the moment, ObjectStorage's are very exposed in the public api. They are even used as identifier in annotations and therefore pretty much bind the concrete class to the user land code.
- Related to Bug #91387: Relax constraints on serializing objects added
- Status changed from Accepted to Closed
Hey.
I hope it's ok to close here for now: The initial patch has been abandoned and nothing happened for some years.
I hope it's fair to create a fresh issue in case work is continued here.
- Status changed from Closed to New
- Priority changed from Won't have this time to Should have
Hey, I hope it's okay to reopen this issue again, since the pain points of the lazy object storage still seem to be existing and this issue provided a potential path to solve it.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by