ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

First attempt at Data-Into with YAJL parser

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    yajl_stdin_load_tree creates a tree structure in memory (inside the YAJL service program). It does a lot more than just simply read the JSON string into memory. Once loaded into the tree, it is no longer a string containing JSON, it is a bunch of data structures in memory that you can work with using other routines.

    If your goal is to receive the JSON data and then just send it on to something else, there's no need to use YAJL at all. Just use QtmhRdStdin() (an IBM API) to get the original string into memory, and then you can send that string with HTTPAPI (or any other tool.)

    If you need to do both parse/interpret the JSON and still send it on afterwards, then you might still use yajl_stdin_load_tree(), but use yajl_stringify() to get a JSON string from the data that you can send onward.

    Comment


    • #47
      Originally posted by JonBoy View Post
      What I was thinking of was a tool that would simply attempt to generate the required names/hierarchy together with the DIMs etc. where needed. Not a complete solution, but for large complex documents it would sure as heck save some time!
      Jon, Greg, and anyone else who might be interested.

      I took a crack and writing a tool that can generate the RPG data structure for you and called it YAJLGEN, it is included with a new version of YAJL (only in the v7r2 version that contains data-into) that is now on my web site.

      Code:
      YAJLGEN STMF('/tmp/mydocument.json') SRCFILE(mylib/QRPGLESRC) SRCMBR(myrpg)
      As I mentioned a few months ago (earlier in this discussion thread) it has a number of limitations. The biggest limitation is that it cannot tell the "maximum" sizes of things since that info simply isn't in the json. So it simply defines things according to the first instance it finds. For example:

      Code:
      {  "first name": "Ed" }
      This would define an RPG ds like this:

      Code:
      dcl-ds jsonDoc qualified;
        FIRST_NAME varchar(2);
      end-ds;
      So this "sort of" works, but it has no way to know how large a first name can be, since the data it was given contains a 2-character name, it defines it as varchar(2).

      It has the same problem with arrays.
      Code:
      {
         "line items": [
            { "itemno": 1, "price": 9.99 }
         ]
      }
      A human being might look at this and think "obviously an order can have more than one line item", but this code just isn't that smart. It sees only one in the document, and has no way to know there can potentially be more, so it'll create the array like this:
      Code:
      dcl-ds jsonDoc qualified;
        dcl-ds LINE_ITEMS dim(1);
          ITEMNO packed(1: 0),
          PRICE  packed(3: 2);
        end-ds;
      end-ds;
      So a programmer will need to go over the definitions it created and adjust the field sizes and DIM keywords to be the maximum allowed sizes rather than just whatever happened to be found in the document. But, it seems to do a decent job aside from that. Maybe you'll find it useful.

      Comment


      • #48
        Thanks for that Scott - I'll take a look at it later this week when the current crises have passed!

        I think the limitations as you describe them are fine - I would have expected to have to manually adjust such settings.

        Comment


        • #49
          Thank you sir!! This is fantastic! It get's 90% of the work done for you - a human looking at the JSON always has to make decisions on field sizes and array dimensions (and hope it's sufficient). So i don't really consider those "limitations".

          Comment

          Working...
          X