Why, when assigning a parent record to a shared child record, is the parent record itself changed?

  1. In a shared zone you have a root record—call it "Root".

  2. You create a child record, "childA", assign Root as its parent, and write it to the cloud with Operation1.

  3. Before Operation1 has completed, you create a second record, "childB", assign Root as its parent, and write it to the cloud with Operation2.

  4. Operation1 completes without error.

  5. Operation2 completes with an error, saying Parent had changed.

(Presumably, the error in step 5 was because Parent was changed somehow by Operation1, but how—and why? Parent itself did not change, though a reference to it had been created via child1.parent.)

  1. Resend the failed record from step 3 with Operation3.

  2. Operation3 completes without error.

Step 7 succeeded because the parent had been refreshed in the local cache, but why should that matter? And if it does matter, what then is the best practice for rapid and successive additions of child records to a common parent record?

Perhaps I am encountering this issue more because my home internet connection is abysmally slow at the moment, but surely you don't need to synchronously daisy-chain successive child insertions, so what I am missing?

I understand that batching both child insertions into the same operation would sidestep this issue, but the child records are created sequentially by the user (think items in a list) and are written to the cloud separately.

What's the best practice here? (Thanks for your time.)

  • Serialize the operation allowing permitting the root to complete any reference updates.

  • Thank you. Are you suggesting that the parent reference for childA is reused for childB, and the mismatch between the pre-Operation2 parent and the post-Operation1 parent reference is what's causing the error? In other words, that the creation of a parent reference updates/changes the referenced parent, perhaps to update its modification date?

Add a Comment