RequestFactory issue with return operation processing if entities referenced in collection are processed after the collection they appear in is processed

Hi all,

I'm pretty sure this is RF issue but thought I'd post here first just in case.

This involves the case where you update a an entity with a collection in which another entity is being persisted. When the response returns from the server and the operation messages are processed the following will occur:

The ClientId is always zero when parsed out from collections and thus the simpleproxyID lookup in the collection is always done by serverkey. This means that if the collection contains an entity that was created on the client and persisted is processed first then a new simple proxy will be created for that serverkey combo. Now when the actual related entity is processed (afterward) the clientId will be populated and so the system will do the lookup by the client ID for the simpleproxyID and then associate that simpleproxyID

with the serverkey which will override the simpleproxyID mapping created when the factory saw the serverkey first. Since that old mapping was overridden then the related proxy in the collection is not updated and returned as if it were still new with all fields unpopulated. 

This doesn't occur if the persisted entity is processed before the collection since after the IdFactory sees an entity that has both a clienID

and a serverID then it will retrieve the original simpleproxyID and update it the mapping to using the serverID, thus when the serverID is used in the lookup to populate the collection afterward it will find the correct simpleproxyID.

Again, this issue becomes all the more hard to spot since it ONLY occurs if the persisted entity is processed AFTER the collection it is referenced in. Since the order in which the operations being built client side is indeterminate (from the map) you can't tell when the entity will appear afterward.

The fix I had in mind with the big problem being that the returnedProxies mapping must always map from the correct simpleproxyId:

when processing the returned operations if the clientId > 0, we should first check if there's already a simpleproxyid for the serverid, if there is then we need to swap that mapping in state.returnedProxies when the simpleproxyid returned from using the serverid and non-zero client id. That way the mapping in state.returnProxies always maps from the correct simpleproxyid. Since a call to getId always creates a simpleproxyid then we would also need to be able to access the ephemeralId map in order to check it without creating a simpleidproxy. 

Any thoughts?

-Seth

Client ID is always zero when parsed out in collections and thus the simpleproxyID
lookup in the collection is always done by serverkey!!! This means that
if the collection containing an entity that was created on the client and persisted
is read first then a new simple proxy will be created for that serverkey combo
and thus a new proxy will be associated to it. Then when the actual related entity is
read (after the collection having been read) the client Id will be populated and so the system
will do the lookup by the client ID for the simpleproxyID and then associate that simpleproxyID
with the serverkey which will override the simpleproxyID mapping created when the factory
saw the serverkey first. Since that old mapping was overridden then the related proxy in the collection is
not updated and returned as if it were still new. This doesn't occur if the persisted entity
is read before the collection since after the IdFactory sees an entity that has both a clienID
and a serverID then it will store the associated simpleproxyID by then serverID, thus when
the serverID is used in the lookup to populate the collection afterward it will find the correct
simpleproxyID.

Client ID is always zero when parsed out in collections and thus the simpleproxyID
lookup in the collection is always done by serverkey!!! This means that
if the collection containing an entity that was created on the client and persisted
is read first then a new simple proxy will be created for that serverkey combo
and thus a new proxy will be associated to it. Then when the actual related entity is
read (after the collection having been read) the client Id will be populated and so the system
will do the lookup by the client ID for the simpleproxyID and then associate that simpleproxyID
with the serverkey which will override the simpleproxyID mapping created when the factory
saw the serverkey first. Since that old mapping was overridden then the related proxy in the collection is
not updated and returned as if it were still new. This doesn't occur if the persisted entity
is read before the collection since after the IdFactory sees an entity that has both a clienID
and a serverID then it will store the associated simpleproxyID by then serverID, thus when
the serverID is used in the lookup to populate the collection afterward it will find the correct
simpleproxyID.

Client ID is always zero when parsed out in collections and thus the simpleproxyID
lookup in the collection is always done by serverkey!!! This means that
if the collection containing an entity that was created on the client and persisted
is read first then a new simple proxy will be created for that serverkey combo
and thus a new proxy will be associated to it. Then when the actual related entity is
read (after the collection having been read) the client Id will be populated and so the system
will do the lookup by the client ID for the simpleproxyID and then associate that simpleproxyID
with the serverkey which will override the simpleproxyID mapping created when the factory
saw the serverkey first. Since that old mapping was overridden then the related proxy in the collection is
not updated and returned as if it were still new. This doesn't occur if the persisted entity
is read before the collection since after the IdFactory sees an entity that has both a clienID
and a serverID then it will store the associated simpleproxyID by then serverID, thus when
the serverID is used in the lookup to populate the collection afterward it will find the correct
simpleproxyID.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.