JSON representation of MV data

[Kevin Powick]

Is there a published or community "standard" for representing MV data in JSON format?

Converting MV data to JSON is pretty trivial, but I was hoping to find a standard format/layout and naming convention to somewhat hedge bets on cross-vendor compatibility.

If no standard exists, has anything been proposed?

--

Kevin Powick

[Kevin King]

I know of no such standard.  In fact, even outside of MV I haven't seen any cross-vendor standards describing naming conventions (ala EDI).

We use JSON as the standard transport format when moving information out of Unidata/Prelude to the web, using name/value pairs for input and nested objects for output.  Each request is structured slightly differently based on the appropriate response for each request.

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Tony Gravagno]

General response:

 

I've spoken with a few colleagues about this and the consensus seems to be a combination of these factors:

 

- Just doing JSON, like XML, is dirt simple as long as the sample data is as simple.

- The limitation of 3 levels in MV (@AM, @VM, @SM) creates an artificial limit for direct serializing and de-serializing with JSON and XML. The easy and obvious case doesn't stand up to fairly common cases where we need more levels. It becomes apparent early on (for most people I guess) that this kind of work can't be done using 1-for-1 structure translation, and that's what makes it more complex.

- More complexity requires more rigorous code, and few people have undertaken this effort.

- Parsing data isn't so much of a problem, but it's a huge challenge to create a general purpose utility which parses data that needs to be stored into the file system.

- Of those who have done this, the code is now a valuable asset and can't just be given away as FOSS.

- Even if someone is inclined to FOSS it, most of this code wasn't written to be an example of elegance and the code probably isn't offered up simply because it's too convoluted.

- Such code is a constant work-in-progress and opening it up to a wider audience (especially This one) is more likely to draw criticisms about what it doesn't do than collaboration from people who offer to enhance it.

- As with a few others I've spoken to, I'd write and publish a JSON or XML parser/builder if only there was a paying market for it. But people here are so reluctant to pay for what they use that there is a never ending list of things we Don't have in spite of what we Could have. And then people look at this market and say "what? it doesn't have THIS?" It's not the fault of the technology, it's the people who use it.

 

I tend to push MV data into a middle tier where I then massage it for transport elsewhere. For my purposes it's OK to move relatively flat MV data into a strongly typed class and then serialize it in one line with a common non-MV library. Same goes for the other direction. Insistence on doing everything inside the MV box limits options. That said, I agree that it would be nice to have utilities like this, especially if they were usable across all platforms. With that, there are some things that I tend to do outside of the box that I would probably do more directly anyway.

 

T

 

 

 

From: Kevin King

 

I know of no such standard.  In fact, even outside of MV I haven't seen any cross-vendor standards describing naming conventions (ala EDI).

 

We use JSON as the standard transport format when moving information out of Unidata/Prelude to the web, using name/value pairs for input and nested objects for output.  Each request is structured slightly differently based on the appropriate response for each request.

 

Kevin Powick  wrote:

[Symeon Breen]

There is no standard – not in any database – ORM means you can create objects that are useable throughout your business without regard to how that data is actually persisted.

 

So think how you want your json objects to be used and then do your mapping – (maybe instead of ORM it is OmvM  ;)

--

[Kevin Powick]

I guess I should have clarified the "standard" part.  I just meant in terms of  standard 3 level (@am, @vm, @svm) encoding/decoding, strictly for MV systems. 

This would allow for a generic encoder/decoder to be written for working with MV data outside of MV systems, using familiar MV constructs such as  Extract(), Insert(), Replace(), and Delete(),  that we've seen for years in various COM libraries.  Something like the following:

myrec.insert('data',1,4,2)

myrec.replace('info',3,2)

jrec = myrec.toJSON

myrec.fromJSON(jrec)

name = myrec.extract(3)

orderID = myrec.extract(4,2)

Maybe such functionality already exists in the libs from current vendors (RD, BlueFinity, jBASE, QM)?

--

Kevin Powick

[Kevin King]

While that's easy enough to implement, the problem is that flatting a MV structure might not be the best way to structure the JSON packet.  Certainly a single mv'd array is simple as an array, but tandem mv'd arrays might work better as an array of objects instead of an array of arrays.  Consider:

["Charlie","Linus","Lucy"]

...works fine as a single array, but what if each has additional information, like maybe a credit limit?  Flatting two mv'd attributes might turn into this:

[["Charlie","Linus","Lucy"],[100.00,200.00,300.00]]

But it might be easier for the data consumer to work with if the tandem values were stored together in an object, as in:

[{"name":"Charlie","limit":100.00},{"name":"Linus","limit":200.00},{"name":"Lucy","limit":300.00}]

Certainly it's longer, but does the addition of the name/value pairs for identifying specific fields in the object make it worth the additional characters?  I believe it does, especially when the JSON is being consumed by Javascript programming, but of course YMMV.

[Kevin Powick]

Hi Kevin,

Yes, you've illustrated the point of my original question.  There are ways to get MV to JSON format, but is there an agreed upon standard in MV land?  Apparently not.  I think the following might be more a more MV(ish) representation of your example.

{

    "Names": [

        "Charlie",

        "Linus",

        "Lucy"

    ],

    "Limits": [

        100,

        200,

        300

    ]

}

Oh well.  It was just a thought.  We've been moving MV data in and out of systems via XML and JSON for quite some time, so it's not like we're stuck or anything.

--

Kevin Powick

[Kevin Powick]

On Sunday, 23 September 2012 23:21:43 UTC-4, Kevin Powick wrote:

{

    "Names": [

        "Charlie",

        "Linus",

        "Lucy"

    ],

    "Limits": [

        100,

        200,

        300

    ]

}

Whoops!  I guess that's pretty much the same as your first example.  As far as the ease with which the consumer can deal with it, I guess that depends if they're an MV person or not :)

--
Kevin Powick 

[Rich Taylor, InterSystems]

Kevin,

Cache has a pretty good model for handling JSON.  This is largely based on our object technology which encompasses working with Multivalue data.   There are two api calls to go to or from JSON.   JSON output will include an additional key/value pair that indicates the source of the data.  When handling importing from JSON if this special key/value pair is present the api will know what data structure to build.  This would allow you to create the generic process you were looking for.   I wrote a Tip on this which was published on our MV community.  I will hunt that up and repost it here.

Rich Taylor

[Kevin Powick]

On Monday, 24 September 2012 09:52:52 UTC-4, Rich Taylor, InterSystems wrote:

  I wrote a Tip on this which was published on our MV community.  I will hunt that up and repost it here.

Thanks.  Looking forward to reading it.

--

Kevin Powick