One-to-one relationships in the schema configuration files

The parent schema

In the schema extension file, if the parent schema is not already present, then you must add it to the definitions section, and you must add a child properties section.

You must define the one-to-one property. The title and description attributes are optional. The $ref property is required and it must be set to "#/definitions/<nameOfChildSchema>".

For example, the following defines an activityLegalInfo_Ext property in the Activity schema.

"definitions": {
  "Activity": {
    "properties": {
      ...
      "activityLegalInfo_Ext": {
        "title": "ActivityLegalInfo_Ext",
        "description": "One-to-one association to ActivityLegalInfo_Ext",
        "$ref": "#/definitions/ActivityLegalInfo_Ext"
      }
    }
  },

The child schema

In the schema definition file, you must add the new schema definition to the definitions section for the child. You must add a properties section to that definition. Then you must add the following properties:

• A read-only id property whose type is string.
• One property declaration for each field in the one-to-one child that is to be exposed to Cloud API.

For example, the following defines an ActivityLegalInfo_Ext schema, with three properties: id, legalCaseNumber, and legalReviewDate.

"definitions": {
  ...
  "ActivityLegalInfo_Ext": {
    "properties": {
      "id": {
        "title": "ID",
        "description": "Object ID",
        "type": "string",
        "readOnly": true
      },
      "legalCaseNumber": {
        "title": "LegalCaseNumber",
        "description": "Legal case number",
        "type": "string"
      },
      "legalReviewDate": {
        "title": "LegalReviewDate",
        "description": "Legal review date",
        "type": "string",
        "format": "date-time"
      }
    }
  }

The inline child properties are typically scalars, compound datatypes, or foreign keys. For more information on how to configure schemas for these type of properties, see:

• Adding scalars
• Adding compound datatypes
• Adding foreign keys

The parent mapper

In the mapping file, if the parent mapper is not already present, then you must add it to the mappers section, and you must add a child properties section. For the one-to-one field, you must specify the path and mapper.

For example, the following defines an activityLegalInfo_Ext mapper for the Activity schema.

"mappers": {
  "Activity": {
    "properties": {
      ...,
      "activityLegalInfo_Ext": {
        "path": "Activity.ActivityLegalInfo_Ext",
        "mapper": "#/mappers/ActivityLegalInfo_Ext"
      }
    }
  },

The child mapper

In the mapping file, you must add the child mapper to the mappers section with the following properties:

• schemaDefinition - set to the name of the child schema
• root - set to entity.<nameOfChildEntity>

Then, you must add a properties section to that mapper with the following properties:

• A read-only id property whose path is typically set to "<childEntity>.RestId".
• One property for each inline child field. For each property, you must specify its path.

For example, the following defines the mapper for ActivityLegalInfo_Ext, with three properties: id, legalCaseNumber, and legalReviewDate.

"mappers": {
  ...
  "ActivityLegalInfo_Ext": {
    "schemaDefinition": "ActivityLegalInfo_Ext",
    "root": "entity.ActivityLegalInfo_Ext",
    "properties": {
      "id": {
        "path": "ActivityLegalInfo_Ext.RestId"
      },
      "legalCaseNumber": {
        "path": "ActivityLegalInfo_Ext.LegalCaseNumber"
      },
      "legalReviewDate": {
        "path": "ActivityLegalInfo_Ext.LegalReviewDate"
      }
    }
  }
}

• Adding scalars
• Adding compound datatypes
• Adding foreign keys

The parent updater

In the updater file, if the parent is not already present, then you must add it to the updaters section, and you must add a child properties section. For the one-to-one field, you must specify the following attributes:

• path - set to <root>.<foreignKeyToChild>
• create - set to new <childEntity>(<root>)
• updateRef - set to #/updaters/<childUpdater>

For example, the following defines an activityLegalInfo_Ext updater for the Activity schema.

"updaters": {
  "Activity": {
    "properties": {
      ...
      "activityLegalInfo_Ext": {
        "path": "Activity.ActivityLegalInfo_Ext",
        "create": "new ActivityLegalInfo_Ext(Activity)",
        "updaterRef": "#/updaters/ActivityLegalInfo_Ext"
      }
    }
  },
  ...

The child updater

In the updater file, you must add the child updater to the updaters section with the following properties:

• schemaDefinition - set to the name of the child schema
• root - set to entity.<nameOfChildEntity>

Then, you must add a properties section to that updater with one property for each inline field that is to be writeable from Cloud API. For each property, you must specify its path.

For example, the following defines the updater for the ActivityLegalInfo_Ext schema, with two properties: legalCaseNumber and legalReviewDate.

"updaters": {
  ...,
  "ActivityLegalInfo_Ext": {
    "schemaDefinition": "ActivityLegalInfo_Ext",
    "root": "entity.ActivityLegalInfo_Ext",
    "properties": {
      "legalCaseNumber": {
        "path": "ActivityLegalInfo_Ext.LegalCaseNumber"
      },
      "legalReviewDate": {
        "path": "ActivityLegalInfo_Ext.LegalReviewDate"
      }
    }
  }
}

The inline child properties are typically scalars, compound datatypes, or foreign keys. For more information on how to configure updaters for these type of properties, see:

• Adding scalars
• Adding compound datatypes
• Adding foreign keys