Page History

...

1. Read definition from the file.
2. Check if definition already defined by checking if typeId already exist
3. If typeId already exist, validate that the structure being loaded is the same as the already defined type
   1. If type definitions are different throw TypeDefinitionAlreadyDefinedException
   2. If type not defined confirm that all referenced subTypes exist within existing type registry or within the current type definition file. If all types are correctly defined and validated, then load type definition into the type registry.

Type Registry Service API

The type registry service has to provide the following services:

• addTypeDefinitions(List<TypeDefinition>)
• exportTypeDefinitons():List<TypeDefinitions>
• removeTypeDefinitions(List<TypeDefinition>)
• lookupTypeDefinition(long typeDefId):

...

• TypeDefinitions
• lookupTypeIdByTypeDefinition(TypeDefinition):long

...

Proposed Type Definition Format

...

In the below example it shows how to define the type definition for a domain object.

[
  {
    "@type": "JSON_Document",
    "@typeId": 1,
    "fields": [
      {
        "fieldName": "firstName",
        "dataType": "String"
      },
      {
        "fieldName": "lastName",
        "dataType": "String"
      },
      {
        "fieldName": "age",
        "dataType": "Integer"
      },
      {
        "fieldName": "currentAddress",
        "@refTypeId": 2
      },
      {
        "fieldName": "previousAddresses",
        "dataType": "List",
        "@refTypeId": 2
      },
      {
        "fieldName": "luckyNumber",
        "dataType": "List"
      },
      {
        "fieldName": "dateOfBirth",
        "dataType": "Date",
        "format": "MM/dd/yyyy"
      },
      {
        "fieldName": "lastUpdated",
        "dataType": "Date",
        "format": "MM/dd/yyyy hh:mm:ss:SSS"
      }
    ]
  },
  {
    "@type": "JSON_Document",
    "@typeId": 2,
    "fields": [
      {
        "fieldName": "addressLine1",
        "dataType": "String"
      },
      {
        "fieldName": "addressLine2",
        "dataType": "String"
      },
      {
        "fieldName": "addressLine3",
        "dataType": "String"
      },
      {
        "fieldName": "state",
        "dataType": "String"
      },
      {
        "fieldName": "zipCode",
        "dataType": "String"
      },
      {
        "fieldName": "country",
        "dataType": "String"
      }
    ]
  }
]

Example JSON document with typeIds

{
  "@typeId": 1,
  "firstName": "John",
  "surname": "Doe",
  "currentAddress": {
    "@typeId": 2,
    "addressLine1": "Suite 200",
    "addressLine2": "1235 South Rd",
    "addressLine3": null,
    "state": "OH",
    "zipCode": "287233",
    "country": "USA"
  }
}

In the above example we are using the type definitions from the Custom External Type Definition Proposal for JSON above. As one can see not all the fields have been populated but is still referencing the type definition for typeId 1. In the previous implementation the above example JSON document would have caused a new type to have been generated, but in this case, the type registry was told that this JSON object belonged to the type defined by id 1 and was mapped accordingly.