Closed dmfenton closed 6 years ago
1. don't generate an objectid automatically at all (this may break some clients) . This will definitely break ArcGIS Pro and likely others
2. calculate a numeric hash of a feature (this may hurt performance) This can be done using farmhash, but it results in a 32bit unsigned integer, which can result integers greater than the maximum ObjectID value for ArcGIS Pro (2,147,483,648)
3. generate a random object id per feature (unknown effect on arcgis clients) If these are not persisted across requests, this unfortunately leads to errors in Pro and others. For example, if one loads the attribute table, IDs there can become out of sync with those points on the map that may get generated on follow up requests. So table selects, identifies, and "zoom to feature" functions can fail.
4. add a numeric prefix that maps to the source request where the source features were requested (may be some complex logic here if the clients try to query the source for the same individual feature) I think this is what will need to be done..
Fixed in FeatureServer 2.11.0 and winnow 1.14.0. Used the numeric-hashing method noted above, but rescaled the output so max hash is 2,147,483,648.
When there is nothing specified in
metadata.idField
FeatureServer (by way of Winnow) will generate objectids automatically starting from zero. Because it always starts from zero you could have different source features given the same objectid. This results in bugs due to caching by ArcGIS clients.Relevant code is here:
https://github.com/koopjs/winnow/blob/master/src/executeQuery.js#L66 https://github.com/koopjs/winnow/blob/master/src/executeQuery.js#L79-L84
FeatureServer and Winnow should avoid this situation with a more intelligent way of generating object ids.
Some options: