I have a recurring project where I update a geodatabase every quarter. The geodatabase contains a feature class with relationships to multiple tables. Because of this update schedule, I also overwrite the feature service published to ArcGIS Online each quarter from ArcGIS Pro.
With the last update, I noticed that the relationship index changed between each relationship table. In the web map feature class popup, this change of relationship index disrupted a line chart in the that uses one of the related tables.
Is anyone aware of how ArcGIS Pro or ArcGIS Online determines the relationship index during publishing when multiple relationship classes exist in the geodatabase? Or, is there a way to to ensure that the same relationship index is created each time I overwrite the feature service?
If the relationship indices are randomly assigned, maybe this needs to fixed so that there is a system so this error does not persist. If I have to update the line chart after every feature service overwrite, that will be very annoying.
Please get into touch with tech support to investigate further. Are you updating the data by completely changing the data or are you adding new data? I'm wondering if append may be helpful for your workflow.
Thank you for your reply. I think I will need to do some more testing to see if this issue persists before I am ready to reach out tech support, as my sample size is just one instance. It is possible that it could be fine the next time, which may not be for a few months.
In regard to using the append features of ArcGIS Online, unfortunately, I must change the data completely every time due to the ever-changing nature of the raw data sources, which I don't have control over. I have tried many times to see if an append method could work, and it produces more issues rather than making the workflow easier.
We do honor the relationship Id only when publishing Service definition file (SD) only. For fileGDB publishing the relationship Id is incrementally assigned. Is there any reason why relationship Id is important? You might need to dynamically discover the relationship Id from the layer metadata. I will add this as enhancement and see if we can preserve the relationship Id across all feature service implementations. Will post back an update.
Thanks for responding. The relationship ID is required when creating a line chart from a related table in the popup in ArcGIS Online. When the ID changed (from 7 to 4, for example...there are 8 different 1:M relationships in this dataset), the popup was not able to access the correct table to create the line chart, and therefore, it did not show up in the popup. When I investigated why this was, I realized that it had to do with relationship ID. I was able to easily fix it, but I had to redo it manually. Which, the whole point of the line from a related table in the first place was to avoid this. The relationship ID is also used in popups that reference fields from related tables, so this issue is beyond my case.
I am publishing the FileGDB from ArcGIS Pro by overwriting the feature service after each quarterly update. From your comment, it seems that the issue may lie in how ArcGIS Pro organizes the relationship IDs when creating the SD file. I would expect that the relationship IDs are created in order either alphanumerically or by Object Class ID in the FileGDB. But in my case, neither is true. It actually seems random.
If it is random, I speculate may indicate that their creation could be from an unordered data structure in the source code (such as a Python dictionary...but I know that ArcGIS Pro source is not coded in Python). Therefore, this could be a simple fix in the source code. I create the geodatabase from a Python script, so the names of the relationships classes and the order in which they are created is consistent each iteration.
Let me know if this helps. Thanks.
Any update on this? it is a much needed enhancement for us, we have many dependencies on the relationship IDs and keeping them static is very important to not interrupt these. Can you share some more info on the workflow you mention that will honor the relationship ID when publishing a service definition? I would like to be able to overwrite an existing service or restart it without having the relationship ids change