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).
Parent topic: Schema Flexibility with JSON Columns in Duality Views
Footnote Legend
Footnote 1: This differs from the definition in Merging Fields from JSON Flex Columns into Documents, in that columnextras
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.