1 answer
- 10-1
Hello, Enrique Cadalso , at the moment, there are no plans on deprecating it.
I'd actually suggest to use syncRequest.remoteSyncEventNumber == 1 (on connections that have syncBack configured) instead (even though it's not directly saying, that sync is caused by sync back), it's consistently same on all the platforms.Regards, Serhiy.
- Enrique Cadalso
Hi Serhiy,
Thanks for the suggestion. I will use syncRequest.remoteSyncEventNumber == 1 instead.
One caveat of that option is that, for troubleshooting purposes, we can inspect the replica and see the replica.__SYNC_BACK_ON attribute on the "remote replica" using the "Entity Sync status" option on Exalate, but I we won't be able to see the value of syncRequest.remoteSyncEventNumber had on the last replica.
Thanks again,
Enrique
Add your comment...
Hello,
We are trying to make sure only some fields are updated when syncHelper.syncBackAfterProcessing() is used. There are some warnings at https://docs.idalko.com/exalate/display/ED/syncBackAfterProcessing but the provided solutions are far from clear.
There is this undocumented __SYNC_BACK_ON attribute on the remote replica when receiving the data from a syncHelper.syncBackAfterProcessing() on the other side. It is not present when the synchronization is caused by an update.
We are planning to use it like this
Is it safe to use it? Is it going to be deprecated any time soon? Is there any documentation about this attribute?
Thanks.