Thoughts on JSON structures / schemas / templates

[Doug Easterbrook]

hi Nick.

you are going to need a dictionary of some sort that describes your data structure with names of fields, types, lengths, etc so that you can build your json.    Our rest api is very extensive and lets people get at almost any endpoint in the data model.  While we implemented it in python, we still needed to describe the data model.  you can’t get around that

In omnis: file, schema or query classes can help you since they contain information about your data fields you want to manipulate.

it just happens that these describe the same data model as python code and we could have implemented our rest api in omnis - except for the fact that our web servers are python.


so, back to omnis.   We have a file class for every schema class.  In other words  every table in our database has both file and schema (they are the same definitions).   There is a historical reason for file classes (i.e we used to use DML).  There is still a nice reason to have file classes:

1) we use them with oWrite to merge in data fields
2) we use them throughout omnis to get a fields ’table name’, $objtype,  $objsubtype, etc
3) we store dictionary information into the $info class on the file

Over time, we added things to the dictionary like column visibility (can user see it or not), exportability (some things aren't worth it like binaries) , left/right justification, whether it has decimal and displays ‘$’, etc. (for headed list display).


what comes out of that for us?     in a nutshell, a lot of what we build on our omnis screens, headed lists, exports are data driven.



Most rest api endpoints I’ve seen are build on tables.  so if your database has 20 tables, you have 20 endpoints.      Sometimes it is convenient to consolidate an endpoint so that it is a join of two or three tables - but usually not so much, especially if you want to have a write api.


that basically makes it a one to one correspondence with a database table, a schema, a file class  and (if you want) a query class.


me, I’d probably use query classes since they can be a subset of a schema.  You are still faced with the notion that you need a query class for each end point.   and query classes have a drawback — they are just names of variables.

this is where or schema classes come in.    ’The dictionary’.   Its easy to build a list of columns in a query.   so then its easy to get their dictionary info from the file class (or schema class if you prefer).

query classes let you read the data into a list that you can export using $jsontolistorrow  

query classes don’t have to exist (a schema does).  you can build a query class instance dynamically for the export and destroy it later if you want.  (for that matter, you can do the same with a schema class).




so, my thinking is

1) ask user what data they want (usually thats a feature of a json export)

eg, I wants columns  first_name,  Last_name, Company, and record #

2) make a query based on those columns   (or a schema)

3) read data into list

4) adjust as necessary based on your dictionary (i.e. hide some columns, redefine if need be, give a different column title such as chance _xx_first_name to firstName for export, whatever)

5) make the json equivalent of the data

6) export the json data

7) delete the query class 





I’m just imagining what you are up to —  but some approach like the above should help make it data driven.


Hope that helps.










Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at artsman.com
http://www.artsman.com
Phone (403) 650-1978

> On Jun 12, 2019, at 4:24 AM, Nick Renders <omnis1 at arcict.com> wrote:
> 
> Hi List,
> 
> I am thinking about implementing some calls to a third party REST Service into our Omnis Libraries, but before I paint myself into a corner, I wanted to see if anyone had any thoughts on / experience with the subject.
> 
> The service is your typical HTTP REST server:
> - there are different endpoints (URI) we can call, with different (CGI) parameters
> - each request has some mandatory and custom headers
> - a request can have a body (JSON)
> - if the request is successful, a JSON is returned as result
> 
> 
> The goal is to set up an environment that can be entirely customisable by the Omnis user: the requests (endpoint, parameters, header, body) are defined somewhere and are automatically generated with the correct data when sending a request. If any updates need to be done to the request (new parameters, nodes added or removed from JSON, ...), the user can do this in a GUI without having to change any Omnis code.
> 
> Basically, it means that there are some JSON templates with links to variables that will populate the nodes. I have been thinking on what might be the best way to define these JSON templates / structures, and so far I have come up with three possibilities:
> 
> 1) save an "empty" JSON as a character field.
> 	PRO: easy and fast to code and implement
> 	CON: hard to define how the nodes should be populated (which variables to use)
> 
> 2) save a list / row variable as a binary field.
> 	PRO: easy and fast, e.g. with the OJSON.$jsontolistorrow function
> 	CON: still not sure how to link variables (for instance, an integer column cannot hold the variable's name)
> 
> 3) use schema classes (and save as binary field?).
> 	PRO: the Description column can be used to specify variable names or other options
> 	CON: lots of array / object nodes means lots of (sub-)schemas
> 
> 
> Currently, I am favouring the third approach, but I am reluctant to create so many schema class. On top of that, it also means that any changes are made in the library directly, so there will be a need to somehow save those in a centralised database as well.
> 
> 
> Does anyone have any thoughts or tips on this? Has anyone done something similar, defining JSON structures and populate them with data? Any feedback is very much welcome.
> 
> 
> Thanks,
> 
> Nick Renders
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com