How do we handle conflicts when using ApplyEdits?

Question

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?

JeremyBridges · Answer

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..."}

]

}

ThomasJones1 · Answer

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.

JeremyBridges · Answer

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?