OpenG Variant toolkit: How to rename element within (nested) cluster?

[nickster]

I have a project that's making heavy use of JKI JSON in conjunction with OpenG Variant toolkit. For a bit of context, I'm communicating with an instrument server via JSON-RPC over websocket.

I can access properties of the server by sending a "Query" command, with an empty JSON object corresponding to the desired property in the "params" field. In Labview, it looks something like this:

which ends up sending a JSON-RPC message like this to the server:

{
    "jsonrpc":"2.0",
    "method":"Query",
    "params":{
        "filter":{
            "SomeNumericValue":{
            }
        }
    },
    "id":"bar"
}

 

From time to time, I need to query data that's returned in the form of a dictionary. For example, the server maintains a database of user-defined instrument settings, with each settings object labeled by a guid string. I can retrieve all dictionary elements in one go with an empty object labeled "{}". Then I can restructure them into a more LV-amenable array using OpenG Variant tricks. So far so good. The Labview looks like this:

Just for total clarity, the JSON-RPC message sent from my client looks like this:

{
    "jsonrpc":"2.0",
    "method":"Query",
    "params":{
        "filter":{
            "SomeDictionary":{
                "{}":{
                }
            }
        }
    },
    "id":"bar"
}

 

Unfortunately, the full database can be really big and unwieldy. Each item in the dictionary is itself a pretty bulky object. (Side note: I sadly think I've discovered that it can break the JKI JSON parser. I'm not sure how this happens - maybe a memory issue when recursion gets really, really deep. Don't shoot me if I'm wrong about that. JKI JSON is saving my life right now, so I don't want to speak ill of it!) I would really like to query just one dictionary element at a time. In terms of how my code currently works, that would require changing the wildcard "{}" label within the filter object structure to the actual name of of the item I want to grab. (Knowing the item names is no problem. I can retrieve a list of names from a separate query.)

So far I haven't figured out how to do this. Maybe it's not even possible. (Just wiring a variant to Set Data Name.vi and then using Bundle's to build up a cluster doesn't work. The element in the cluster will be named "Renamed Data" - i.e., the output name of Set Data Name.vi.)

For the record, no, I do not like the fact that the server spits out dictionaries, as these naturally map onto a cluster of clusters (object of other named objects), and Labview desperately wants all objects to already be named at runtime. But this is just how the device works, and I can't change it.

Edited September 10, 2019 by nickster

[drjdpowell]

One suggestion is to use Variant-to-Data to convert your Cluster-in-a-Variant to an Array of Variants containing the Cluster elements.  Then use the Data type palette to get element names.  This will be much faster and less memory intensive than using OpenG Vis.

[drjdpowell]

If you can access the original JSON string, then you have more options to convert it, such as with the in-built JSON primatives or JSONtext, both of which should be quicker and use less memory.  The code would be simpler too.

[nickster]

16 hours ago, drjdpowell said:

One suggestion is to use Variant-to-Data to convert your Cluster-in-a-Variant to an Array of Variants containing the Cluster elements.  Then use the Data type palette to get element names.  This will be much faster and less memory intensive than using OpenG Vis.

Thanks. I'll take any speed-ups I can get. But when I sit down to wire this up, I realize I'm not understanding the instructions. Could you show an example diagram?

 

16 hours ago, drjdpowell said:

If you can access the original JSON string, then you have more options to convert it, such as with the in-built JSON primatives or JSONtext, both of which should be quicker and use less memory.  The code would be simpler too.

Early on in development I had tried out both the built-in LV JSON tools and JSONtext, as well as one or two other JSON toolkits on the market. My focus then was just on getting a solution up and running, not on performance benchmarking. I went with JKI purely on this basis. I recall that there was something smoother about retaining some subset of data within a cluster in variant form for later typecasting. LV JSON, I think, was an absolute no-go from this standpoint, and JSONtext was a maybe-go if I had allowed myself to play around with it more. I will come back to JSONtext and try to implement it - would be nice if I can get a performance boost.

As for dealing with the JSON string itself, yes, I can go there, but code reuse will go in the toilet.

Regarding the original problem of programmatically renaming an element in a (variant of a) cluster, I found a workaround for my application by instead building up a new cluster from scratch using OpenG. I'm not sure whether anyone would describe it as "elegant."

Edited September 11, 2019 by nickster

[drjdpowell]

33 minutes ago, nickster said:

But when I sit down to wire this up, I realize I'm not understanding the instructions. Could you show an example diagram?

This idea, though it is a request for the reverse operation, illustrates how one can convert a cluster (in a variant) into an array-of-variants that contain the individual cluster elements.   This did not exist when the OpenG Variant Tools were made, and OpenG is based on the (much slower) operation of manipulating flattened data.

[drjdpowell]

37 minutes ago, nickster said:

As for dealing with the JSON string itself, yes, I can go there, but code reuse will go in the toilet.

Don't quite understand that. JSON is a standard data format, widely reusable. Your weird Variant/Cluster/Dictionary thingies are very non-standard.

[nickster]

26 minutes ago, drjdpowell said:

This idea, though it is a request for the reverse operation, illustrates how one can convert a cluster (in a variant) into an array-of-variants that contain the individual cluster elements.   This did not exist when the OpenG Variant Tools were made, and OpenG is based on the (much slower) operation of manipulating flattened data.

Ah, that's a cool trick. Thanks.

 

25 minutes ago, drjdpowell said:

Don't quite understand that. JSON is a standard data format, widely reusable. Your weird Variant/Cluster/Dictionary thingies are very non-standard.

Food for thought. Reconsidering my position...

[drjdpowell]

A JSONtext example, ssumming all dictonary items are the same type:

 

Alternately, keep items in JSON format so they can be treated differently at a later step: