21 Migrating From JSON To Duality

The JSON-To-Duality Migrator can migrate one or more existing sets of JSON documents to JSON-relational duality views. Its PL/SQL subprograms generate the views based on inferred implicit document-content relations. By default, document parts that can be shared are shared, and the views are defined for maximum updatability.

• JSON Columns in Duality Views
  With JSON Relational Duality, developers can leverage JSON documents for data access while using the highly efficient relational data storage model, without compromising simplicity or efficiency.
• About Migrations From JSON To Duality
  Learn about the JSON-To-Duality Migrator use cases for existing and new applications.
• JSON To Duality Migrator Components: Converter and Importer
  The JSON To Duality Migrator has two components: the converter and the importer. Their PL/SQL subprograms are described.
• JSON Configuration Fields Specifying Migrator Parameters
  You configure JSON-to-duality migration by passing a migrator configuration object as argument to PL/SQL DBMS_JSON_DUALITY subprograms infer_schema, infer_and_generate_schema, and import_all. The supported fields of such an object are described.
• School Administration Example, Migrator Input Documents
  Existing student, teacher, and course document sets comprise the JSON-to-duality migrator input for the school-administration example. In a typical migration scenario each might be received in the form of a JSON dump file from another database.
• Before Using the Converter (1): Create Database Document Sets
  Before using the JSON-to-duality converter you need to create JSON-type document sets in Oracle Database from the original external document sets. The input to the converter for each set of documents is an Oracle Database table with a single column of JSON data type.
• Before Using the Converter (2): Optionally Create Data-Guide JSON Schemas
  A data-guide JSON schema provides frequency information about the fields in a document set, in addition to structure and type information. You can use such schemas to get an idea how migration might proceed, and you can compare them with other JSON schemas as a shortcut for comparing document sets.
• JSON-To-Duality Converter: What It Does
  The converter infers the inherent structure and typing of one or more sets of stored documents, as a JSON schema. Using the schema, the converter generates DDL code to create the database objects needed to support the document sets: duality views and their underlying tables and indexes.
• Migrating To Duality, Simplified Recipe
  By ignoring whether an input field occurs rarely, or with a rarely used type, it's easier to migrate to JSON-relational duality. Handling such outlier cases can complicate the migration process.
• Using the Converter, Default Behavior
  Use of the JSON-to-duality converter with its default configuration-field values (except for minFieldFrequency and minTypeFrequency) is illustrated. In particular, configuration field useFlexFields is true. The database objects needed to support the document sets are inferred, and the SQL DDL code to construct them is generated.
• Import After Default Conversion
  After default conversion (except for minFieldFrequency and minTypeFrequency), in particular with useFlexFields:true), almost all documents from the student, teacher, and course input document sets are successfully imported, but some fields are not exactly as they were in the original, input documents.
• Using the Converter with useFlexFields=false
  Use of the JSON-to-duality converter with useFlexFields = false is illustrated. Otherwise the configuration is default (except for minFieldFrequency and minTypeFrequency). The database objects needed to support the document sets are inferred, and the SQL DDL code to construct them is generated.
• Import After Conversion with useFlexFields=false
  After trying to import, error-log tables are created and queried to show import errors and imported documents.
• Errors That Migrator Configuration Alone Can't Fix
  Even if you configure the migrator to not consider any fields or their values to be outliers, the migrator can detect other kinds of problems. A simple example shows detection of data contradiction between different document sets.