The similarity between JSON objects + arrays and Globals in IRIS or Caché is evident.
With small and medium size JSON objects navigation across %Dynamic Objects is comfortable.
But with large and/or deep cascaded objects it becomes a challenge.

The presented tool offers 3 variants

• loading an already existing %Dyamic object or Array into a global of your choice
• loading a %Stream containing a JSON object into a global of your choice
• loading an external File containing a JSON object into a global of your choice

How to use it

USER>read str
{"id":306904,"last_star_ts":0,"completion_day_level":{},"global_score":0,"local_score":0,"stars":0,"name":"name_1"}
USER>set jsn={}.%FromJSON(str)
USER>write ##class(rcc.jstog).toglobal(jsn,"^jsn")
1
USER>zwrite ^jsn
^jsn("global_score")=0
^jsn("id")=306904
^jsn("last_star_ts")=0
^jsn("local_score")=0
^jsn("name")="name_1"
^jsn("stars")=0

USER>zzjson jsn
{
  "id":306904,
  "last_star_ts":0,
  "completion_day_level":{
  },
  "global_score":0,
  "local_score":0,
  "stars":0,
  "name":"name_1"
}
USER>

from an already existing Stream, it's like this

USER>write ##class(rcc.jstog).stream(jsonstream,"^jsstr")
1

and from a file it is this method:

USER>set filename="/opt/irisbuild/src/data/demo.json"
USER>write ##class(rcc.jstog).file(filename)  ; using default gloabel ^jsom
1
USER>

File content:
 

Global content:

This might not look so spectacular.
But see and try the difference with a 6 MB sized JSON Object.

Video

GitHub

Some technical background information

There is not just one class in this package:  rcc.gstream.cls but also rcc.gstreamT.cls

While rcc.gstream works with direct access to the stream globals, the *T version uses
a Process Private Global (PPG) as Temporary storage.
using  SELECT * FROM RCC.gstreamT WHERE RCC.useT('^jpgS')=1 and similar.

This might be an advantage for multiple access to the same stream in sequence,
The advantage is obvious: You have a personal snapshot in memory and no risk of
a conflict in access. This might be interesting if you work just on 1 specific stream.
The disadvantage is also evident: The merge from Stream Global to PPG takes time. 
 
As a side effect I learned that the compression of stream variants GblChrCompress,
and GblBinCompress only affects the global size on disk. Once in memory, it consumes
the full size, and therefore with xDBC the full uncompressed stream gets sent over the
connection.
Differently, inside IRIX/Caché/Ensemble you only get to the stream's OID. Which makes
sense as streams typically exceed the maximum String length. To visualize this I did
something unusual as I mixed flat and compressed data into the same global.
So all even IDs are compressed streams.  

The code in the repo is written for IRIS.
But using it in Caché/Ensemble/... only requires changing the stream storage type from  
<Type>%Storage.SQL</Type> in IRIS to  <Type>%CacheSQLStorage</Type> for C/E

The base for both classes is Global mapping with SQL Storage.
And it was quite an exercise to make it dynamic.
My personal thanks go to Mike LaRocca who created a presentation about 20 years ago
that I found in my personal archives together with a related similar aged document
"Mapeo de Clases persistentes en Globales"  from a Spanish engineer
who's name was not mentioned there.

As a bonus for those who try the package, there is a medical jpeg not shown in the video.
I guess you will recognize the person immediately.

Hoping for your votes in the tools contest  !

Video

GitHub