How do we handle conflicts when using ApplyEdits?

929
4
02-20-2020 07:57 AM
JeremyBridges
Occasional Contributor

Updating or deleting a record that does not exist causes the entire ApplyEdits call to fail with 400 "Object is Missing" and no other information. We think we may need to either query for records before calling ApplyEdits in attempt to pre-detect potential conflicts or call ApplyEdits once per feature for updates and deletes in order to determine which features are problematic. What is the recommended approach to better handle these situations?

0 Kudos
4 Replies
ThomasJones1
Esri Contributor

Hello Jeremy Bridges‌,

You may want to try including a 'rollbackOnFailure' parameter and set the value to 'false'. If false the server will apply any edits that succeed even if some edits fail. The default value is 'true' in this case the edits are applied only if all edits succeed. Hope this helps!

Apply Edits (Feature Service)—ArcGIS REST API: Services Directory | ArcGIS for Developers 

Thanks,

Thomas.

0 Kudos
JeremyBridges
Occasional Contributor

Our clients mainly use versioned data for everything. From what we've learned about rollbackOnFailure, it cannot be set to false for versioned data. So unfortunately, this approach is viable for us.

Is our best practice here to query for possible conflicts before applyEdits, or is there another, more attractive approach?

0 Kudos
ThomasJones1
Esri Contributor

Hello Jeremy Bridges‌,

You are correct to set rollbackOnFailure = true the data needs to be non versioned. To my knowledge you would need to query the service in order to only delete or update existing records.  

Thanks,

Thomas.

0 Kudos
JeremyBridges
Occasional Contributor

Alright. Could you give us a better picture of why this is the only remedy? Is it dependent to the fundamental nature of the database infrastructure a geodatabase relies on (relational database)?

Also, can we get a better error message? "Object is Missing" doesn't communicate enough for an application to manage the transaction in a more automatic fashion. At the very least, we'd love to see the response body contain the layer ID and GlobalID/ObjectID of the problem record. Something like:

{

   "error": {

      "code": 400,

      "message": "Update failed on object from 'Transformer' layer, GlobalID 'abc....' - object doesn't exist"

      "details": [

         {"layerID": 0},

         {"globalID": "abc..."}

      ]

   }

}

0 Kudos