Hey Jay -
On a related question, why does the Update a Feature output leave large gaps in the OBJECTID sequence when it creates new features? In a class where the highest existing OBJECTID was less than 10, the GeoEventProcessor created features started with OBJECTID 810. |
Many times, when using the 'Add Features' or 'Update Features' capabilities on a feature service, I have observed that one set of edits will use OBJECTIDs 1, 2, 3, 4 ... and see a second set of edits jump to begin using OBJECTIDs 401, 402, 403, ...
This is actually by design, and has nothing to do with the GeoEvent Extension. My understanding is that this is an attempt by ArcGIS Server to avoid conflicts when multiple contributors (or multiple web applications) are making edits to a feature class through a feature service's REST endpoints. By detecting, somehow, that a second editor is making edits, that second editor will be assigned a block of IDs (401, 402, 403, ...) so that features they add and update will not interfere with likely requests a previous editor is making to add and update features.
You can easily see this if you add a feature service's layer to a web map, begin editing, then in a different window POST an Esri Feature JSON record to the feature layer's 'Add Features' endpoint, then return to the web map and continue adding/editing features.
This is the primary reason why we introduced date/time support when polling a feature service for incremental updates. We had assumed (wrongly) that if a GeoEvent input were to cache the last (largest) OBJECTID retrieved we would be safe in querying for OBJECTIDs greater than our largest observed value. What we found was that we would often miss features that the first contributor had created; once we began querying in the 401, 402, 403, ... range we would never pick up features created in the 5, 6, 7, 8 ... range of OBJECTIDs.
- RJ