Marco Pivetta
added a comment - 03/Apr/12 12:38 AM - edited I am personally for dropping the `$_identifier` field and using the entity fields themselves. Will check this tomorrow. (also: not sure if it is possible, just checking)

This is not fixable. The Proxy requires access to the Entity Persister when unserialized, but that is not available anymore. Proxies are broken if unserialized and then accessed, i believe an exception is thrown in this case.

Benjamin Eberlei
added a comment - 07/Apr/12 7:41 AM This is not fixable. The Proxy requires access to the Entity Persister when unserialized, but that is not available anymore. Proxies are broken if unserialized and then accessed, i believe an exception is thrown in this case.

Benjamin Morel
added a comment - 07/Apr/12 11:30 AM Of course they cannot be initialized once unserialized, but should'nt be merge()able to a new EntityManager anyway?
What I would imagine is:
Serialize the identity as part of the proxy
If used when unserialized, throw an exception (see http://www.doctrine-project.org/jira/browse/DDC-1732 )
If found during a merge(), replace the proxy with a fresh proxy/entity from the current EntityManager

Benjamin Morel
added a comment - 30/Oct/12 6:21 AM @Marco Pivetta This is a great idea. Have you checked if it is possible?
I'm really surprised that a proxied entity's identity is lost forever upon serialization.

Matthieu Napoli
added a comment - 30/Nov/12 1:42 PM Can this issue be reopened please?
As Benjamin Morel said, it is expected that the proxy is broken once unserialized, but it should be possible to merge to the EntityManager and then use it.
For now, objects graphs with proxies can't be serialized! It could be if the merge would resolve the situation.
I'm giving it a try by serializing the $_identifier field in the Proxy
Thanks

@ocramius I will make a pull request on Github and post the link here.

However I'm sort of stuck right now: I've added '_identifier' to the fields serialized, but it's not enough. To merge, the UoW needs to initialize the proxy to get the identifiers (because $_identifier is private in the proxy). Problem: $_entityPersister (used to initialize the proxy) is also private.

So I can neither get the identifier of the proxy (even for creating a new proxy for example), nor feed it a new entityPersister to load it... The solution would be to change the proxy a bit (like adding a "__setEntityPersister" method for example) but I guess that changing the Proxy interface in "Doctrine\Common" is a large change and that will not be accepted as a pull request...

Matthieu Napoli
added a comment - 30/Nov/12 4:22 PM @ocramius I will make a pull request on Github and post the link here.
However I'm sort of stuck right now: I've added '_identifier' to the fields serialized, but it's not enough. To merge, the UoW needs to initialize the proxy to get the identifiers (because $_identifier is private in the proxy). Problem: $_entityPersister (used to initialize the proxy) is also private.
So I can neither get the identifier of the proxy (even for creating a new proxy for example), nor feed it a new entityPersister to load it... The solution would be to change the proxy a bit (like adding a "__setEntityPersister" method for example) but I guess that changing the Proxy interface in "Doctrine\Common" is a large change and that will not be accepted as a pull request...
Any ideas ?

Marco Pivetta
added a comment - 30/Nov/12 4:23 PM Matthieu Napoli I wouldn't start hacking on that right now... The new impl allows injecting an initializer. A hack may be ok-ish, but the API is already at its EOL.

Matthieu Napoli
added a comment - 30/Nov/12 4:42 PM - edited Marco Pivetta I'm working on the master branch, it's 2.4 right? I don't see anything different for the proxies in this branch (I don't see any way to inject an initializer).
Or is it your PR ( https://github.com/doctrine/common/pull/168 ) maybe?

Benjamin Morel
added a comment - 30/Nov/12 5:09 PM I'm happy that this bug is taken care of, I think that's a major problem that's been dismissed a bit quickly.
Can the bug be reopened, with fix version 2.4, to avoid forgetting it once more?

Just to be clear: I created 2 test methods, the first one works (there is no serialization step), the second doesn't. This is to make it clear that the serialization step is the problem. I hope this is alright.

Matthieu Napoli
added a comment - 03/Dec/12 8:57 AM - edited Marco Pivetta Sorry the test was on my computer at work, here it is now: https://gist.github.com/4193721
Just to be clear: I created 2 test methods, the first one works (there is no serialization step), the second doesn't. This is to make it clear that the serialization step is the problem. I hope this is alright.

Marco Pivetta No those aren't 2 different cases, they are the same, it's just that one fails because we use serialization (this is the problem described in this ticket), and the other one works because we don't use serialization (and it only exists to check that everything works if we don't use serialization). Actually I think the "working test" has no reason to exist really, I just made it to "prove" that the problem was indeed the serialization, so it can be removed.

Matthieu Napoli
added a comment - 03/Dec/12 9:33 AM Marco Pivetta No those aren't 2 different cases, they are the same, it's just that one fails because we use serialization (this is the problem described in this ticket), and the other one works because we don't use serialization (and it only exists to check that everything works if we don't use serialization). Actually I think the "working test" has no reason to exist really, I just made it to "prove" that the problem was indeed the serialization, so it can be removed.