Safe-ishly "Upgrade" flattened cluster

[avogadro5]

---

@drjdpowell wrote:

---

@avogadro5 wrote:

---

@drjdpowell wrote:

Have you considered just saving as JSON, rather than flattened clusters?

---

With the built-in JSON unflatten, I have been unable to unflatten into a cluster with different elements than the original cluster that was flattened, even when it should be "obvious" how to adapt such as adding a new uniquely named attribute.

I'm trying to avoid using a serializer addon that includes the code to interpret each potential type as I have learned not to trust that kind of addon very much.

---

Well, the limited use of the inbuilt JSON primitives are why other JSON libraries exist.  I wrote JSONtext myself, and from that experience I can see that making the subVI you want is certainly possible, though you didn't convince me that the JKI one doesn't already work.

---

The JKI one doesn't support collections. It also doesn't strictly match the input default's datatype.

[drjdpowell]

Comments on your example:

---

I'm trying to guarantee the type of a variable doesn't change at runtime so one check I've added is to only accept value updates via the "data string" which asserts a compatible memory structure

Are you not using strict-typed data in your program?  Libraries like JSONtext assume you are converting to some strict-typed structure like a Cluster, with any Variant being an intermediate step in conversion.  Strict-type data can't change at runtime, so I don't understand what you are doing here.

would like an error/warning or another output letting me know some JSON was not understood

This has been requested before, so I might add a "Missing Items" output in JSONtext.

Though other ways of doing data-type changes from old versions are:

• include a "Rev" or "Format Revision" element in the JSON that you read first, just a number that tells you what version of the data structure is saved, thus allowing mutation code
• Have code to test the JSON, like checking if "a" or "q" exists, thus knowing what version you are handling an triggering mutation code

Having a Dialog to ask the User is a much weaker design than including code that automatically handles older formats of the data. 

For example, 'in Revisions earlier than 2 "q" was named "a".' 

Or even, 'in Rev earlier than 2, if "High Power" = True, then set "Power Level (%)" = 90'

[Yamaeda]

---

@avogadro5 wrote:

---

@Yamaeda wrote:

It works well with to/from flattened variants, just add some filler 0x00's to the flattened string so there's some data to convert from.

---

If I'm understanding this correctly is it suggesting that I would have to inspect the 2 datatypes and insert padding string(s) to make the old string compatible with the new one?

---

Kind of. If the new type has more data it'll create an error if there isn't enough to work with. If you test with the opposite, a smaller cluster, it'll take as much data as it needs and ignore the rest.

With that in mind, if you just add a bunch of nulls the new/added elements should get default values.

[avogadro5 · Accepted solution]

There appears to be no existing code with the features I'm looking for. Thanks for the input that what I want to do is wrong.