How to globally get rid of PersistentCollection?

Question

PHP

Good afternoon.
I have one complex document in my project, made up of several EmbeddedDocuments of rather large nesting - a player profile in an RPG game. In total, about 50 classes are involved in the document. In places, inclusion via @EmbedMany is used, which gives PersistentCollections when hydrating documents. Almost all classes were automatically generated by thrift-compiler, so adding methods to them that will clear the PersistentCollection seems to me a bit unnatural. Then, according to these generated classes, doctrine odm mappings were generated in the form of yaml files.
Task: Download player profile from mongodb using doctrine odm and write to thrift.
Problem: thrift's pure-php implementation handles PersistentCollections just fine. But when trying to write to thrift using TBinaryProtocolAccelerated (and the binary extension thrift_protocol.so enabled), the write fails with an Exception:

Thrift\Exception\TProtocolException: Attempt to send non-object type as a T_STRUCT

Possible solutions (as I see it, in order of priority):

1. Override HydratorFactory with your own class that will not create PersistenCollections: www.doctrine-project.org/api/mongodb_odm/1.0/sourc... . I do not have enough understanding of what pitfalls may arise in this case. Will it blow the roof off to all UnitOfWork and DocumentManagers?
   
2. Use the same thrift to deserialize data from the database, and store the data itself as a long binary string. Minus: I still want convenient access to data in the database. It is possible, in principle, to save data in expanded form + as a binary string, which can be used for thrift-deserialization, but then you get an extra overhead in storage and in communication with the base.
   
3. Write a recursive walker that will replace all collections with their getValues()
   
4. Use another odm like Mandango. You need to experiment, maybe it will work. But the labor costs for connecting this whole thing and writing a mapping generator are still quite significant.
   

Help with advice, please. Maybe I don't see something point-blank, and the task is solved simply and elegantly?

Answer 1

In the end, I went down the third path. Everything works as it should.