THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Reduced PdxType definitions for JSON documents representing the same logical domain object
- Improved performance in processing of JSON documents, as the PdxType, is known and does not have to be determined defined and generated for each submitted document
- Ease of type definition management
- Ability to ingest JSON documents representing the same type with a variance of populated fields
- Ability to export existing type definitions into a human readable format
- Ability to externally register data types
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
{
"@type" : "JSON_Document" | Fully qualified className, <-- The name of the object type being defined
"@typeId" : , <-- A numberic field which would uniquely identify the type
"fields":[ <-- A collection of fields
{
"fieldName" : , <-- The name of the field
"dataType" : "String" | "Integer" | "Double" | "Date" | "Float" | "Boolean" | "Long" | Object (default), <-- The data type of the field (Not required when using @refTypeId)
"format" : "MM/dd/yyyy hh:mm:ss:SSS " | "#0.00" <-- Optional field to provide a format when dealing with dates of doubles
"@refTypeId" : , <-- The reference to an already defined type
},
{
"fieldName" : , <-- The name of the field
"dataType" : "List", <-- Indicates data type is a list/array
"@refTypeId" : , <-- Numeric reference to an already defined type, which will be populated in the list
},
{
"fieldName": , <-- The name of the field
"dataType": "List", <-- Indicates data type is a list/array
"subType": "String" | "Integer" | "Double" | "Date" | "Float" | "Boolean" | "Long" | Object (default) <-- The data type of the elements of a List
"format": "MM/dd/yyyy hh:mm:ss:SSS " | "#0.00" <-- Optional field to provide a format when dealing with dates of doubles
}
}
|
...
| Code Block |
|---|
{
"@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 are used. Not all the fields have been populated but is still referencing that are defined for the type definition for typeId=1. In the previous implementation, the above example JSON document would document would have caused a new type to have been generated, but in this case. In the proposed solution, the type registry was told informed that this JSON object belonged to the type defined by id typeId=1 and was mapped accordingly.
...