I'm looking at deploying some new templates in Ignition and need to store some data as memory values. I've found this could be done simply by using memory tags as numbers or strings, but also using the document tag type and storing the data as JSON. This would be for a perspective application as well. Is there any major pro's/con's to be aware of going one way or the other? The data stored would not be regularly changed, mostly static.
Leave the documentation properties for, ehm, documentation. If you need something special then create a custom property of the appropriate datatype on the tag and put the information there. You would then, of course, document that in the documentation property (wouldn't you?).
I think he means using an actual document tag, not the document prop.
1 Like
Yes the document tag.
Hmmph! I never heard of it. It doesn't show up in my tag creation options. What is it?
Document is a data type available for any kind of tag. It's a JSON object structure - so a map of string keys to arbitrarily deep nested JSON elements.
If that's really true, then sure, use documents, though they don't give you a ton of benefit other than (potentially) housing all your values in that single tag, if that's important to you. Performance wise I would expect many small tags with simpler data types to work a bit better, but it likely doesn't really matter.
We have tested this as we were wondering as well. We have three "designs" Storing metadata as individual tags, one using a metadata document tag, and one using a metadata property on a tag.
This test was done making 100,000 parent tags. Using individual tags used between 1.5 to 2 GB as a baseline. Using the other two designs used quite a bit less memory, 780 MB and 700 MB respectively. I think having a separate document tag would be the best way to tackle this design.
5 Likes
As ever, actual testing beats gut feelings every time 
It's probably only true at relatively large scales where the overhead adds up, but definitely useful data to keep in mind.
Interesting results Kyle_Chase. In playing around in Perspective it seems simpler to interact with custom properties on a tag vs using json commands to retrieve and set values of document members and having to do transforms. Maybe the only benefit that a document tag would be separate from other values etc? Just not sure I see the value in the added complexity of a document tag vs custom props.
It comes down to personal preference. Having a bunch of properties on a single tag also works, but woiuld require multiple tag reads to access all data, vs a single metadata property or tag.
Thank you @Kyle_Chase for doing the deep work on this. Answered a lot of questions we had for our implementation and what the benefits/concerns were. Likely will use the document tag for tracking metadata at the folder level and not store the same data multiple times across tags.