Duplicate tags in TAGCONFIG?

Ignition
1

I know I'm wandering through unsupported territory, but I'm hoping I can get some unofficial help from the community.

Our production server has around 1 million tags on MQTT Engine. I am trying to export those tags' configs for analysis/backup/whatever. You cannot export MQTT Engine tag configs normally in Designer. Trying to do it in scripting with system.tag.getConfiguration thrashes the server pretty hard and seemed to miss many tags. I couldn't find a reason why tags were being misssed, and was feeling nervous about repeatedly thrashing the server just to try again. For better or worse, I decided to take a recent copy of the production config.idb SQLite file, and make my own offline exporter tool.

All in all, the process wasn't awful, but I've found some inconsistencies in the TAGCONFIG table along the way that I suspect are debris left behind over the years from issues in Ignition.

If anyone wants to have a discussion about the concept of a TAGCONFIG-fsck, I've got a lot to say, but for now I have one particular oddity I can't figure out: I'm finding many pairs of TAGCONFIG rows that have the same FOLDERID and NAME. I can't tell which one is "dominant" or if Ignition is somehow merging them when it loads the TAGCONFIG table.

Has anyone ever gone this deep into TAGCONFIG and have any helpful comments?

2

I tweaked my utility to show a diff of the duplicate tag configs in an easy-to-view format, and started looking for a pattern. I also started opening up tags one by one in Designer to see what the actual config in use looked like. From every tag I looked at this way, it seems to be that Ignition uses the TAGCONFIG row with the higher ID value, as though the one with the lower ID doesn't exist. The two row configs are not merged.

I have no guarantee this is always true, but I was able to quickly determine that it was correct for every tag in a set of over 100 that I could recognize which config was correct.

:confused:

3

You're definitely deeply in the weeds of "implementation details", so I can't offer much, but I'm pretty confident that your experimental finding is correct - the ordering by id is relevant to semantics in the event of a tie. Don't know enough about the inner semantics to know why you'd have otherwise duplicates appended instead of replacing each other :man_shrugging:

1 Like