I am storing a Json structured object to a local tag for local copies of a remote provider tag structure. I ended up doing it with jsonEncoding a string and storing it to a string memory tag.
However I noticed there is also the tag type “Document” that I would think is talking about document storage, which I would think would store a JSON directly but I am struggling to find any info in the manual about it other than it being mentioned here: https://docs.inductiveautomation.com/display/DOC80/Tag+Data+Types
Any ideas?
Tags with Document DataType basically hold any JSON element, typically an object.
Thank you for the clarification! That is what I was thinking but I wasnt positive.
This saves me having to jsonEncode and jsonDecode it on the way in and out, and having to replace all
of the “u”'s in u'string' to 'string' as well!
For reasons I don’t remember we landed on the datatype being called Document instead of JSON. Something about JSON being just an encoding and document databases and… something? I don’t know, I was in the JSON camp.
Might be good if somewhere in the documentation it better explains that, I struggled to find it anywhere
p.s. I definitely like JSON better than Document hahaha
2 Likes
Yeah, I can understand the reasoning. The 'N' in JSON stands for "Notation". So JSON is always considered to be a string with a certain structure to it.
The name "document" on the other hand makes it very difficult to search for information. But, as far as I can see, there is no documentation around it.
Would it be possible to write something here?
https://docs.inductiveautomation.com/display/DOC80/Tag+Data+Types
1 Like
Hmm, ran into something strange. When reading from a document tag, you get a python dict for which you can read the keys directly.
But when writing a dict to a document tag, it doesn’t seem to do anything. I need to wrap it in a system.util.jsonEncode (so make it a string) before I can write it. Is this expected behaviour? Because it’s certainly surprising to me.
2 Likes
I would think this is not expected behavior. I think that initially the purpose of the document was to mimick a perspective property set, and so it is actually created as a Document and DocumentElement. So in order to actually write stuff to it, or read it and then write to its child objects, you have to convert it into an actually python dictionary, then back into a string to write it.
I would presume that the document being so new, and perspective being so new, it hasnt been as heavily used yet for enough people to find all of the little bugs with it like that. For instance, Document is an option for a Vision client tag, but immediately throws an error when you try to create one. The unfortunate side effect of this, is that while the bug tickets get created, they probably dont get addressed as they only affect a small subset of people using the relatively new feature.
But to clarify, I would absolutely LOVE for the Document tag to be treated like a regular python dictionary in reading, writing, editing etc. Especially to be able to reference and manipulate it without having to read it and then write it again. It is extremely valuable when you are using document storage for a project, and are able to use tag events to create your document through a document tag and then log it to the database.
Agreed. I think I messed around with Document types for maybe a total of 10 minutes, realized "Huh, this seems kind of un-intuitive.", and moved on.
Don't hold your breath for this one--just like datasets, Ignition's change propagation mechanisms rely on immutability of the core object. Even if you can change it in place (which actually is possible for the BasicDataset class), those changes won't be (can't be, I think) distributed to subscribers.
2 Likes
What do you mean here by "subscribers"?
Dealing with perspective, I have found many opportunities where having gateway scoped properties could be really useful, and really the end reason for wanting this. Unfortunately I dont think that within the tag system there is really a good way to do this. There would just need to be something to the effect of "project properties" or "gateway properties" similar to the session props. However I recognize this is very specifically valuable to Perspective, as much of Visions 'typical' formats can be easily used within the tag structure. But I dont forsee it happening anytime soon, just a dream hahaha
I meant tag change listeners, specifically, which are the driving mechanism for all change event generation. They "subscribe" to the tag and are notified when changes occur. Which then propagate according to the needs of the specific kind of subscriber, like tag bindings (both Vision and Perspective) and tag change event scripts.
1 Like
I also wouldn't want it to do a (blocking?) write to tags every time I change a property. I'd prefer to control the write myself. Though writing a dict directly would be handy.