Select to view content in your preferred language

Are OBJECTIDs subject to change? If so, how can you reliable update a specific record using /updateFeatures?

434
8
a week ago
nickbhe
Emerging Contributor

I always assumed that OBJECTIDs were static, persistent, unique identifiers for a record in an Enterprise Geodatabase, but am now learning that may not be correct. I've found comments in various Stack Exchange / ESRI Community threads indicating that a record's OBJECTID may be re-assigned:

I cannot, however, find any official ESRI documentation supporting this. So, my first question is: Is there any official ESRI documentation that definitely states whether OBJECTIDs are persistent or ephemeral?

Second, the /updateFeatures documentation states that "the attributes property of the feature should include the object ID", and as far as I can tell this is the only piece of information it uses to determine which record to update. But if OBJECTIDs can change, how can you reliably update a specific record using /updateFeatures? It seems to me the best you could do is hit /query using a different unique identifier to look up the record's current OBJECTID, then hit /updateFeatures ASAP and cross your fingers that it doesn't change. 

For additional context: this issue came up because we integrate with an external system that updates certain attributes on our Feature Services. That system uses a queue to handle outgoing /updateFeatures payloads. That queue became blocked and is now attempting to process relatively old (~1-2 weeks) records.

Many of those payloads are failing, and it appears the reason is because the OBJECTIDs in those payloads no longer exist in our Feature Service. The records still exist (we can find them using different unique identifiers), but their OBJECTIDs are not the same as the ones included in the payloads, implying that they changed since the payload was created. 

 

0 Kudos
8 Replies
Laura
by MVP Regular Contributor
MVP Regular Contributor

I'm under the impression they don't change unless it's one of the exceptions listed here: https://support.esri.com/en-us/knowledge-base/what-are-the-differences-in-the-behavior-of-the-object...

 

nickbhe
Emerging Contributor

That does seem to suggest that they generally shouldn't change outside of exports. Of course deletion/reinsertion would create a new object id as Calvin noted, but in my head that isn't really changing the object ID on an existing record, it's just creating a brand new record. These docs also do specify that they apply to ArcMap 9.x and 10.x, but we are on AGE 11.1 ... that was actually part of the reason for my post, most of what I can find about object ids is in old ArcMap documentation, can't find much of anything from ESRI related to 11.x ArcGIS Enterprise on the subject. 

0 Kudos
CalvinHarmin
Frequent Contributor

If any of your workflows on the Enterprise GDB feature class performs a truncate/append style operation, or delete/re-insert, or possibly if the data is replicated from another source, OBJECTID's will not be a valid way to uniquely identify features since the OBJECTID values will be applied simply based on order of insert operations. However, if your workflows only are updating existing rows, then OBJECTID's should not be changing.

Since you do indicate you are using Enterprise GDB, I believe that means you could use a Database Sequence and an Arcade expression to generate a custom unique ID field with an Attribute Rule instead of relying on OBJECTID/GLOBALID. Are you familiar with that strategy? However, if any of your workflows are re-inserting rows, then the Attribute Rule would need some logic to keep a uniqueID if it already exists, rather than always generating a new ID on an insert. 

I see this from the  /updateFeatures  documentation that this would be supported in 11.5 to use a custom unique id string field instead of objectid or globalid:

CalvinHarmin_0-1759153383647.png

EDIT: This seems more complicated than I thought:

https://developers.arcgis.com/rest/services-reference/enterprise/layer-feature-service/#new-at-115 

0 Kudos
nickbhe
Emerging Contributor

Generally, we do not delete/reinsert records, only update them. Thank you for the suggestion on using Arcade + DB Sequences to generate a custom unique ID. But we do already have a custom field that stores unique IDs, but per my reading of the /updateFeatures documentation clients must use the object id (or perhaps global id?) to specify which feature to update.

I did also notice that useUniqueIds parameter on /updateFeatures that you mentioned but unfortunately, we are on 11.1, so it is not available to us. 

0 Kudos
nickbhe
Emerging Contributor

I'll look into this more ... do you know if global IDs be used in lieu of object IDs in /updateFeatures payloads?

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

More information would have to be shared before community members could provide anything beyond anecdote and links to general documentation.  For example, is this a hosted feature service or a referenced one?  If referenced, what is the back-end data store and what style of versioning is being used with the data?  Depending on the answers to these questions, there are even more questions.

0 Kudos
nickbhe
Emerging Contributor

We are running ArcGIS Enterprise 11.1, and the Feature Services are referenced not hosted. The back end datastore is an Oracle Geodatabase (Oracle 19, I believe). No versioning is applied on the feature classes that back these services.

I will say that I'm not so much looking for a solution the underlying issue here so much as clarity the specific questions bolded in my original post.

0 Kudos