(Original creator: eknochs)
I recently read a few articles raving about how good PostgreSQL is. One article in particular explained how great it is that they have a JSON data type. I wondered exactly what that would mean for developers, and whether Uniface needs one too. The PostgreSQL documentation states that JSON data can be stored just fine in a text data type, but that a specific data type for JSON adds specific validation for JSON strings. The documentation then adds that there are related support functions available. Indeed there are JSON operators and functions that massage data between JSON strings and table rows and columns. Suppose that you have a use case to exploit these functions, should you use them? The simple answer for a Uniface developer is “of course not”. Looking at those JSON support functions I would suggest that you can write Uniface functions / local proc modules to manipulate and transform data in similar ways. Uniface Structs and the new 9.6.04 structToJson and jsonToStruct statements are particularly helpful for this.
So, provided that there is no extreme performance advantage in doing such manipulation on a DB server, it would not be a good idea to tie your application to a specific DB vendor, and lose that DBMS independence that Uniface gives you. Bear in mind that there is no JSON data type in the current SQL Standard from 2011, and the major RDBMS vendors have not found a need to add such a non-standard extension. Since we do have JSON manipulation tools, there is another consideration, based on our experiences with XML. How do we validate the meaning of data transported by JSON? With the xmlstream data type (and supporting proc statements) we have DTDs. With our Structs transformations we have XML schema validation support. With Uniface entities, we have the full support of the application model. What is missing is a JSON Schema mechanism. Thus I would suggest that if there is no supporting validation mechanism, there is no point in having a specific data type for JSON. That situation may change in the future. There are Internet Engineering Task Force (IETF) drafts available for a JSON Schema standard.
If you want to anticipate this as future standard, you can use this online tool to generate a JSON Schema: http://www.jsonschema.net from a sample JSON data stream. At this time, to use this draft JSON Schema, you will need to write a validation module yourself. However, you may be able to validate the data based on the Uniface Application Model. After loading the Struct with the jsonToStruct statement, you may want to prepare the Struct for using the structToComponent statement. Since 9.6.05+X501 the structToComponent supports a /firetriggers command option, which causes the Pre Save Occurrence and Post Save Occurrence triggers to be fired, thus allowing you to do further occurrence based validation or manipulation. Of course the entities that you use for this purpose can be dummy entities created for this purpose, modelled or not. This would avoid the need to reconnect with the database.
Hopefully we now have enough tools to deal with JSON data, without the need for a new data type.