8.1 Embedding Values from JSON Columns into Documents

The value of a field mapped to a JSON-type column underlying a duality view is embedded, as is, in documents supported by the view. There's no conversion from a SQL value — it's already a JSON value (of any JSON-language type: object, array, string, number,…, by default).

Consider table person, with three relational columns and a JSON-type column, extras, whose values must be JSON objects:Foot 1


CREATE TABLE person (
  pid    NUMBER PRIMARY KEY,
  first  VARCHAR2(20),
  last   VARCHAR2(20),
  extras JSON (OBJECT));

Duality view person_embed_dv includes all of the columns of table person. Here is the view definition, in GraphQL and SQL:Foot 2

GraphQL:

CREATE JSON DUALITY VIEW person_embed_dv AS 
  person @update @insert @delete
    {_id       : pid,
     firstName : first,
     lastName  : last,
     moreInfo  : extras};

SQL:

CREATE JSON RELATIONAL DUALITY VIEW person_embed_dv AS
  SELECT JSON {'_id'       : p.pid,
               'firstName' : p.first,
               'lastName'  : p.last,
               'moreInfo'  : p.extras}
    FROM person p WITH UPDATE INSERT DELETE;

An insertion into table person must provide a JSON object as the column value, as in this example:

INSERT INTO person VALUES (1,
                           'Jane',
                           'Doe',
                           '{"middleName" : "X",
                             "nickName"   : "Anon X"}');

Looking at table person shows that column extras contains the JSON object with fields middleName and nickName:

SELECT p.* FROM person p;
PID FIRST  LAST EXTRAS
--- -----  ---- ------
  1 Jane   Doe  {"middleName":"X","nickName":"Anon X"}

Selecting the resulting document from the view shows that the object was embedded as is, s the value of field moreInfo:

SELECT pdv.data FROM person_embed_dv pdv
           WHERE pdv.data."_id" = 1;
{"_id":1,"firstName":"Jane","lastName":"Doe",
 "moreInfo":{"middleName":"X","nickName":"Anon X"}}

Similarly, when inserting a document into the view, the value of field moreInfo must be an object, because that field is mapped in the view definition to column person.extras, which has type JSON (OBJECT).

Embedding a JSON object is just one possibility. The natural schema flexibility of JSON data means that if the data type of column person.extras were just JSON, instead of JSON(OBJECT), then the value of field moreInfo could be any JSON value — not necessarily an object.

It's also possible to use other JSON-type specifications, to get other degrees of flexibility: JSON(SCALAR), JSON(ARRAY), JSON(SCALAR, ARRAY), etc. For example, the JSON-type modifier (OBJECT, ARRAY) requires nonscalar values (objects or arrays), and modifier (OBJECT, SCALAR DATE) allows only objects or JSON dates. See Creating Tables With JSON Columns in Oracle Database JSON Developer’s Guide.

And you can use JSON Schema to obtain the fullest possible range of flexibilities. See Validating JSON Data with a JSON Schema in Oracle Database JSON Developer’s Guide. By applying a JSON schema to a JSON-type column underlying a duality view, you change the logical structure of the data, and thus the structure of the documents supported by the view. You remove some schema flexibility, but you don't change the storage structure (tables).



Footnote Legend

Footnote 1: This differs from the definition in Merging Fields from JSON Flex Columns into Documents, in that column extras is not labeled as a flex column.
Footnote 2: This differs from the duality-view definition in Merging Fields from JSON Flex Columns into Documents, in that (1) column extras is mapped to a field (moreInfo) and (2) it is not labeled as a flex column.