-
Notifications
You must be signed in to change notification settings - Fork 386
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CollectionSyncUpTarget is relying on Id not ExternalId #2337
Comments
Hi @aureosouza, could you provide your entire test |
Sending you the
|
We suspect it could have something to do with the decision making of which requestType and eventually the API to be choosen here in BatchSyncUpTarget: Because it's seems only when |
The way it is currently implemented and documented is to do an upsert instead of a create for locally created records if there is an external id field name in the target definition that is populated on the record. |
@wmathurin the issue we are facing is that we did 2 sync up, one creating and another editing, but no sync down. So we do not have yet the Id from Sales Force, that's why we believe that we should still perform an UPSERT with the The reproduction steps and the error output returned by Sales Force API are all described above and it's critical scenario in our application with the new version 10.1.0, please let us know if we can provide any more info. |
There should be no need to sync down. After a sync up, we update the id on the local record with the id returned by the server. See this code which runs for both BatchSyncUpTarget and the new CollectionSyncUpTarget. To be sure I follow, you run the sync up with the config you pasted above twice. The first time after the record was locally created and the second time after it was locally updated
Before 10.1.0 you were using BatchSyncUpTarget, and it was working correctly? |
I have been testing locally and see the server id saved back on the record (in SmartStore) after the upsert as expected. |
Thanks for info, we confirmed SDK was saving the SF Id after the first syncUp. Issue seems to be that when upserting locally the Id was not being passed, only the externalId so SDK was updating the value of Id to null (which seems like wrong behaviour as well in |
Some steps in debugging process that may help with investigation:
5.1) SyncUp with target:
5.2) In
com.salesforce.androidsdk.mobilesync.target.BatchSyncUpTarget
syncUpRecords hasrecords
:And mergeMode is
OVERWRITE
5.3) In
com.salesforce.androidsdk.mobilesync.target.CompositeRequestHelper
the methodsendAsCollectionRequests
hasrequest
:We believe here the api to be chosen should be the
composite/sobjects/SobjectName/ExternalIdFieldName
from here, and theExternalId__c
should be passed . Since we should rely only on externalId not the SF Id, since this record is created in mobile app.Obs. 1: We noticed in some cases the correct api
composite/sobjects/SobjectName/ExternalIdFieldName
is called on creation of the record and syncUp, but when updating the value it syncs up with the apicomposite/sobjects
which relies on Id not externalId and we are getting MALFORMED_ID response error from SF.Obs. 2: We noticed as well that the
referenceId
is always passed from PR as this is a part of sObject Tree not sObject Collections which could be possible issue:sobjects
which relies on Id not externalIdsobjects/SobjectName/ExternalIdFieldName
that does not rely on IdThe text was updated successfully, but these errors were encountered: